Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-03-27T17:57:44Zhttps://invent.kde.org/plasma/kdeplasma-addons/-/issues/10ESO POTW2023-03-27T17:57:44ZGregor DüsterESO POTWhttps://www.eso.org/public/images/potw/
It's not exactly a POTD, but I'd love to see it included. I guess I'd also submit a MR if desired.https://www.eso.org/public/images/potw/
It's not exactly a POTD, but I'd love to see it included. I guess I'd also submit a MR if desired.https://invent.kde.org/plasma/kde-gtk-config/-/issues/8accent-color2023-03-22T12:40:38ZFushan Wenaccent-color5.27https://invent.kde.org/plasma/kde-gtk-config/-/issues/7color-scheme2023-03-28T06:58:03ZFushan Wencolor-scheme5.27https://invent.kde.org/plasma/kde-gtk-config/-/issues/6font-*2023-03-22T15:02:23ZFushan Wenfont-*5.27https://invent.kde.org/plasma/kde-gtk-config/-/issues/5Sync more config entries with gsettings2023-08-24T01:34:14ZFushan WenSync more config entries with gsettings- [x] `color-scheme`: The preferred color scheme for the user interface. Valid values are “default”, “prefer-dark”, “prefer-light”.
- [ ] `accent-color`: The preferred accent color for the user interface. Valid values are "blue", "teal",...- [x] `color-scheme`: The preferred color scheme for the user interface. Valid values are “default”, “prefer-dark”, “prefer-light”.
- [ ] `accent-color`: The preferred accent color for the user interface. Valid values are "blue", "teal", "green", "yellow", "orange", "red", "pink", "purple", "brown", "slate".5.27Fushan WenFushan Wenhttps://invent.kde.org/plasma/kde-gtk-config/-/issues/4.gtkrc-2.0 still gets re-created in spite of GTK2_RC_FILES2023-03-22T06:16:23ZGhost User.gtkrc-2.0 still gets re-created in spite of GTK2_RC_FILESWhen using the _GNOME/GTK Settings Synchronisation Service_ within KDE Plasma 5.27.3, the service continues to re-create a config file at `~/.gtkrc-2.0` despite the fact that the `GTK2_RC_FILES` environment variable is set and points to ...When using the _GNOME/GTK Settings Synchronisation Service_ within KDE Plasma 5.27.3, the service continues to re-create a config file at `~/.gtkrc-2.0` despite the fact that the `GTK2_RC_FILES` environment variable is set and points to `$XDG_CONFIG_HOME/gtk-2.0/gtkrc`.https://invent.kde.org/plasma/kdeplasma-addons/-/issues/9runners/datetime: How to handle finding standard vs daylight saving time?2023-03-20T21:16:44ZFushan Wenrunners/datetime: How to handle finding standard vs daylight saving time?The following discussion from !361 should be addressed:
- [ ] @nclarius started a [discussion](https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/361#note_645924): (+1 comment)
> Ah, it's because Pacific Standard Time...The following discussion from !361 should be addressed:
- [ ] @nclarius started a [discussion](https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/361#note_645924): (+1 comment)
> Ah, it's because Pacific Standard Time (the other result that's supposed to be found for "PST") is only in effect from November to March, the rest of the year it's daylight saving time ("PDT") so that's why now suddenly it doesn't find it anymore. There's already a fixme comment in the runner code about this but I failed to realize the issue also applies to Pacific Time when writing the tests.
>
> I see several possible solutions:
> - I take back my comment about reverting your change, and we keep the test case as-is, or remove it altogether. We already have the Brazil case in place to check that several matches in the same name category will be shown
> - We set the system clock in the tests to some controlled time, so the matches would be produced independently of when the tests are run - if this is technically possible
> - We check for matches of the time zone name at several time points and not just now, perhaps 1st of January and 1st of July of the same year, so the runner would always find both winter and summer time, and then show the name and time for the currently active variant; eg "PST" during summer would find and show PDThttps://invent.kde.org/plasma/discover/-/issues/21Reapply b9515062 to offline updates2023-03-15T23:56:49ZAlessandro AstoneReapply b9515062 to offline updatesTiny tracking issue to make offline upgrades use `getUpdatesDetails` with the set of ids rather than looping over each resource: there may be too many.Tiny tracking issue to make offline upgrades use `getUpdatesDetails` with the set of ids rather than looping over each resource: there may be too many.https://invent.kde.org/plasma/kwin/-/issues/140Implement tearing with front buffer rendering2024-03-06T01:50:28ZXaver HuglImplement tearing with front buffer renderingThere's three reasons for why I want to do this:
- progress on the kernel side for tearing on atomic modesetting is moving at a glacial pace
- the currently proposed API is *very* limited. With front buffer rendering, you could do tearin...There's three reasons for why I want to do this:
- progress on the kernel side for tearing on atomic modesetting is moving at a glacial pace
- the currently proposed API is *very* limited. With front buffer rendering, you could do tearing without adhering to those limitations
- even ignoring API and driver problems there's also hardware limitations; some hardware can't do async pageflips at all, some can only do it if no overlays are in use etc
Front buffer rendering also has some disadvantages that need to be kept in mind:
- rendering directly to the front buffer can lead to *very* bad artifacts. We'd need to render to an offscreen buffer and blit that to the front buffer to reduce those, which introduces overhead
- when using tiled buffers, even a simple blit can potentially cause noticeable glitches. It might be a requirement to use a linear buffer for scanout
On the implementation side the complexity shouldn't be too high; the main things to consider are that this will introduce a shadow buffer again and that we need to avoid doing atomic commits that wouldn't actually update any planes because the same buffer is re-used.6https://invent.kde.org/plasma/plasma-mobile/-/issues/244[kcms/nightcolor] Night Color info text is partially off screen (Screenshot)2023-03-14T23:47:25ZJustin Zobel[kcms/nightcolor] Night Color info text is partially off screen (Screenshot)![Screenshot_20221210_131155](/uploads/2a802a5a6a993a6fc4feffa44cde3ff6/Screenshot_20221210_131155.png)
Text at bottom of image describing when color changes will happen.![Screenshot_20221210_131155](/uploads/2a802a5a6a993a6fc4feffa44cde3ff6/Screenshot_20221210_131155.png)
Text at bottom of image describing when color changes will happen.https://invent.kde.org/plasma/plasma-mobile/-/issues/243[kcms/virtualkeyboard] Keyboard KCM Sound Feedback toggle doesn't do anything2023-07-16T09:35:21ZJustin Zobel[kcms/virtualkeyboard] Keyboard KCM Sound Feedback toggle doesn't do anythingCan hear sounds from my device normally, music etc but no keypresses in the test box or in Spacebar for example.Can hear sounds from my device normally, music etc but no keypresses in the test box or in Spacebar for example.https://invent.kde.org/plasma/plasma-mobile/-/issues/242[kcms/hotspot] going back and then into hotspot when on shows it as off2023-03-14T14:39:09ZJustin Zobel[kcms/hotspot] going back and then into hotspot when on shows it as off1. Enable hotspot
2. Hit the back button top left
3. Go back into hotspot and it will show as off
However, my device is still connected to the hotspot meaning it's still on.1. Enable hotspot
2. Hit the back button top left
3. Go back into hotspot and it will show as off
However, my device is still connected to the hotspot meaning it's still on.https://invent.kde.org/plasma/plasma-mobile/-/issues/241[kcms/cellularnetworks] allow user to manage cellular networks without polkit2023-12-24T03:59:06ZJustin Zobel[kcms/cellularnetworks] allow user to manage cellular networks without polkitThe user doesn't need elevation on Android or iOS (that I know) to change cellular network info, it shouldn't on Linux either IMHO. Esepcially phones as they're mostly single-user devices.
I think a polkit rule/exemption like Discover h...The user doesn't need elevation on Android or iOS (that I know) to change cellular network info, it shouldn't on Linux either IMHO. Esepcially phones as they're mostly single-user devices.
I think a polkit rule/exemption like Discover has would be sufficient.https://invent.kde.org/plasma/plasma-mobile/-/issues/240[kcms/cellularnetwork] APN seems to be forgotten2024-03-08T21:33:39ZJustin Zobel[kcms/cellularnetwork] APN seems to be forgottenI've set it a few times and it seems to just be forgotten as the chosen item.I've set it a few times and it seems to just be forgotten as the chosen item.https://invent.kde.org/plasma/plasma-mobile/-/issues/239[kcms/hotspot][ux] - enable wifi automatically if off instead of showing erro...2023-03-14T15:29:27ZJustin Zobel[kcms/hotspot][ux] - enable wifi automatically if off instead of showing error when enabling hotspot```
Failed to create hotspot user-hotspot
Connection 'user-hotspot' is not available on device wlan0 because device is not available
``````
Failed to create hotspot user-hotspot
Connection 'user-hotspot' is not available on device wlan0 because device is not available
```https://invent.kde.org/plasma/plasma-desktop/-/issues/82[Approved] Plasma 6 proposal: remove the concept of icons in the Plasma theme2023-08-18T17:45:37ZNate Graham[Approved] Plasma 6 proposal: remove the concept of icons in the Plasma themeOnce upon a time, this was implemented so that System Tray icons and other icons on the panel could be monochrome. This looked better than putting a jumble of colorful icons on the panel, and still looks better today.
However, it causes...Once upon a time, this was implemented so that System Tray icons and other icons on the panel could be monochrome. This looked better than putting a jumble of colorful icons on the panel, and still looks better today.
However, it causes a lot of subtle edge-case issues and user confusion, because now there are two sources of icons, and the rules for which source gets used where are unclear and unpredictable. Everything mostly works when using the Breeze icon theme and Breeze Plasma theme, but anytime you switch one or both of those to a theme that doesn't match with the other, all kinds of subtle icon source bugs crop up and your panel looks weird in random-seeming ways. See all the bugs in the "See also" list of https://bugs.kde.org/show_bug.cgi?id=438191
I'd like to propose for Plasma 6 that we remove the concept of icons in Plasma themes; instead, icons would always come from the icon theme for simplicity and comprehensibility.
---
Relatedly:
To facilitate the legitimate design goal to have monochrome app and plasmoid icons on the panel and not-always-monochrome icons elsewhere in the icon theme (see https://phabricator.kde.org/T10413), we have now settled on using the `-symbolic` suffix for monochrome icons in Plasma 6 and beyond. We now need to do the following:
- In all KDE software, every time we ask for an icon we want to never be colorful, ask for the icon name with `-symbolic` appended
- Rename all of our monochrome Breeze icons to end with -symbolic
(These changes can be done over time and are not mandatory)
---
Merge requests implementing this change:
- All of the work done for https://invent.kde.org/plasma/plasma-workspace/-/issues/82
- https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1640
- https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3138
- https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/439
To test those merge requests, use the Breeze icon theme and a non-default Plasma theme that includes some of its own icons (e.g. Adapta, Layan, Materia) and look for non-Breeze icons in widgets. There shouldn't be any. Then change your icon theme to something other than Breeze. You should see that the new icons from the icon theme apply to Plasma things too now.6https://invent.kde.org/plasma/breeze-gtk/-/issues/7Add missing `-gtk-icon-size` for GTK4 and libadwaita apps2023-03-31T06:32:33ZFushan WenAdd missing `-gtk-icon-size` for GTK4 and libadwaita appsIcons are sometimes too small when GTK4 or libadwaita apps are themed Breeze, which is caused by missing `-gtk-icon-size` in the stylesheet.
| Correct | Wrong |
| ------ | ------ |
| ![图片](/uploads/558980c8018fbaca27235a448b9d5a2b/图片...Icons are sometimes too small when GTK4 or libadwaita apps are themed Breeze, which is caused by missing `-gtk-icon-size` in the stylesheet.
| Correct | Wrong |
| ------ | ------ |
| ![图片](/uploads/558980c8018fbaca27235a448b9d5a2b/图片.png) | ![图片](/uploads/388505da55440efa499086508429c0dd/图片.png) |6Fushan WenFushan Wenhttps://invent.kde.org/plasma/plasma-desktop/-/issues/81Empty CMake variable dumping files in /usr2023-03-26T20:09:23ZJustin ZobelEmpty CMake variable dumping files in /usr
```
/usr/kactivitymanagerd/workspace/settings/qml/activitiesTab/ActivitiesView.qml
/usr/kactivitymanagerd/workspace/settings/qml/activitiesTab/main.qml
/usr/kactivitymanagerd/workspace/settings/qml/activityDialog/GeneralTab.qml...
```
/usr/kactivitymanagerd/workspace/settings/qml/activitiesTab/ActivitiesView.qml
/usr/kactivitymanagerd/workspace/settings/qml/activitiesTab/main.qml
/usr/kactivitymanagerd/workspace/settings/qml/activityDialog/GeneralTab.qml
/usr/kcm_recentFiles/workspace/settings/qml/recentFiles/BlacklistApplicationView.qml
```https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/8Add support for libei (emulated input)2023-08-07T19:03:34ZDark DragonAdd support for libei (emulated input)Plese add support for `libei`: https://gitlab.freedesktop.org/libinput/libei/-/issues/1Plese add support for `libei`: https://gitlab.freedesktop.org/libinput/libei/-/issues/1https://invent.kde.org/plasma/plasma-desktop/-/issues/80Plasma 6 proposal: re-think how desktop icons positions are stored for multi-...2023-05-06T23:04:13ZNate GrahamPlasma 6 proposal: re-think how desktop icons positions are stored for multi-screen arrangements to be more deterministic and robustWe did a big multiscreen overhaul in Plasma 5.27 that overall has been received very well.
But unfortunately it has exposed cracks in how icon positions are stored and mapped to screens/containments/etc. For years we have struggled with...We did a big multiscreen overhaul in Plasma 5.27 that overall has been received very well.
But unfortunately it has exposed cracks in how icon positions are stored and mapped to screens/containments/etc. For years we have struggled with issues relating to icons getting lost or resetting their positions, and I'd like to propose a design document of specific use cases to envision how we can design a more robust solution:
---
## User has 1 screen
Icons don't move unless the user re-arranges them
## User creates new files or folders in `~/Desktop` or moves existing ones there
They're placed on the current primary screen and arranged per the default arrangement rules.
## User increases the physical or logical resolution (e.g. by decreasing the scale factor) of a screen
Icons on that screen don't move, but rather empty space is added to the right and the bottom (at least when using the default icon arrangement settings; when using different ones, empty space may need to be added elsewhere).
Icon positions for the new resolution are saved such that the next time the user uses the same screen arrangement (including screen resolution), the icons return to their positions.
## User decreases the physical or logical resolution (e.g. by increasing the scale factor) of a screen
Empty space to right bottom and to the right of the icons is removed, preserving icon positions as much as possible. If enough space needs to be removed that any icons live in a position that's now gone, they move
Icon positions for the new resolution are saved such that the next time the user uses the same screen arrangement (including screen resolution), the icons return to their positions.
## User connects a new screen with a resolution that has never been seen before
Icons don't move at all.
## User re-arranges some icons on one screen, then disconnects another screen that has no icons on it
Icons on that screen don't move at all.
## User disconnects a screen that has icons on it
Icons on the now-disconnected screen move to the nearest active screen, preferring the positions that they had on the active screen, if there's a saved configuration including those icons with custom positions. If not, they're arranged per the default arrangement rules.
## User re-connects the screen that had icons on it and was then disconnected
The icons that were on that screen before move back to it, in the positions they had when it was connected
## User has always used a complicated three-screen arrangement with the center screen being primary and icons on each screen, and never had any other screen arrangements. The center screen disconnects, then the user adds a bunch of new files or folders to `~/Desktop`
Icons that were on the now-disconnected primary screen move to the new primary screen, per the default arrangement order. Icons newly added to `~/Desktop` are arranged on the new primary screen per the default arrangement rules.
## Now that same user re-connects the original middle primary screen
The icons that were formerly on the middle primary screen return to their positions on it. The icons that were added while the middle screen was disconnected don't move from their current locations on the former primary screen.6