Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-08-24T01:34:14Zhttps://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/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-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/77Remove "Recent Contacts" from Kicker and Dashboard2023-04-11T16:30:41ZNicolas FellaRemove "Recent Contacts" from Kicker and DashboardKicker and Dashboard (but not Kickoff!) have a "Recent Contacts" section that is supposed to show recently contacted people.
It is based on KTP, which is pretty much dead. The "Recent Contacts" feature does not work in any way with the ...Kicker and Dashboard (but not Kickoff!) have a "Recent Contacts" section that is supposed to show recently contacted people.
It is based on KTP, which is pretty much dead. The "Recent Contacts" feature does not work in any way with the regular chat clients people actually use.
It is an effectively dead feature taking up space, we should remove it6https://invent.kde.org/plasma/plasma-desktop/-/issues/75Plasma 6 proposal: if possible, use Breeze LIM by default2023-05-18T10:06:36ZNiccolò VenerandiPlasma 6 proposal: if possible, use Breeze LIM by defaultThere's currently an attempt at implementing Breeze LIMs here: https://invent.kde.org/plasma/breeze/-/merge_requests/126
If I understand that correctly, it should be possible to finish up the implementation for Breeze without big issues...There's currently an attempt at implementing Breeze LIMs here: https://invent.kde.org/plasma/breeze/-/merge_requests/126
If I understand that correctly, it should be possible to finish up the implementation for Breeze without big issues; what really stopped the patch is the additional request to make it a component that could be added to any third party decoration too.
It doesn't look like that's something that someone will implement anytime soon, and I wouldn't want to see the feature wasted for Breeze. In fact, I think it would work nicely as a default. So, if it's possible to finish off the MR, I'd like to see that on by default. What do you think?
![image](/uploads/d079140d856a11e8f827cc746a04e837/image.png)
cc @teams/vdg6Niccolò VenerandiNiccolò Venerandihttps://invent.kde.org/plasma/plasma-desktop/-/issues/74Plasma 6 proposal: full window tinting by default for Breeze Light and Breeze...2023-05-05T21:55:23ZNiccolò VenerandiPlasma 6 proposal: full window tinting by default for Breeze Light and Breeze Dark color schemesI'd like to propose using a little tinting and getting the accent color by the wallpaper by default. This results in very visually pleasing colors:
![image](/uploads/c5f995aaa9e70400897d2adce3d7d4e0/image.png)
Note that wallpaper (espe...I'd like to propose using a little tinting and getting the accent color by the wallpaper by default. This results in very visually pleasing colors:
![image](/uploads/c5f995aaa9e70400897d2adce3d7d4e0/image.png)
Note that wallpaper (especially the default ones) can manually override the accent color, so we can still decide the accent color ourselves even with this option enabled. We could discuss the amount of tinting we deem appropriate.6Niccolò VenerandiNiccolò Venerandihttps://invent.kde.org/plasma/plasma-desktop/-/issues/73[Approved] Plasma 6 proposal: floating panels by default2023-11-18T02:54:50ZNiccolò Venerandi[Approved] Plasma 6 proposal: floating panels by defaultI propose to make the floating panels enabled by default, assuming that they
- De-float when touching a window (including when a window is maximized)
which is implemented, and
- Will gain shadows
- Do not expand vertically when they...I propose to make the floating panels enabled by default, assuming that they
- De-float when touching a window (including when a window is maximized)
which is implemented, and
- Will gain shadows
- Do not expand vertically when they touch a window
both of which should land really soon. Of course, floating can always be disabled by the user if they don't like it.6Niccolò VenerandiNiccolò Venerandihttps://invent.kde.org/plasma/plasma-desktop/-/issues/72[Approved (!)] Plasma 6 proposal: double-click to open files and folders by d...2023-08-18T13:23:27ZNate Graham[Approved (!)] Plasma 6 proposal: double-click to open files and folders by defaultThis was discussed and agreed to at Akademy 2022, but not everyone was there, so I'm opening this issue here to make sure all relevant voices are heard.
---
This debate has been going on for years, and basically boils down to the follo...This was discussed and agreed to at Akademy 2022, but not everyone was there, so I'm opening this issue here to make sure all relevant voices are heard.
---
This debate has been going on for years, and basically boils down to the following positions:
"Single-click is objectively better and more internally consistent for opening items, and those are more important than any concerns about familiarity for migrating users or usability when selecting items."
"Double-click is more familiar to people migrating from other systems and has objectively better usability for selecting items, and those are more important than what's better or more internally consistent for opening items."
FIGHT!
...or not, because over time, distros have been making the decision for us. At the moment, Kubuntu, Fedora KDE, and Manjaro all default to double-click, and these are major distros. Many of the major distros that do not change this setting follow upstream settings (e.g. Arch, Neon, Debian) so not switching doesn't imply satisfaction with the status quo, just a preference for or policy of not changing upstream settings. A couple of other smaller distros also default to double-click, such as NetRunner and FerenOS.
Distros are close to users and clearly the feedback they've been getting is that double-click is a better default.
Let's admit it and switch to double-click by default ourselves.6https://invent.kde.org/plasma/kinfocenter/-/issues/3Use of `qdbus` binary requires that the package providing it be made mandator...2023-02-10T15:05:05ZNate GrahamUse of `qdbus` binary requires that the package providing it be made mandatory, which pulls in a bunch of unrelated developer appsUser installs of Plasma typically include Qt designer, Qt Assistant, Qt Linguistic, and multiple versions of Qt QDBusViewer. This is messy and non-ideal. These apps come from the `qttools` Qt repo, which also includes `qdbus`. And `kinfo...User installs of Plasma typically include Qt designer, Qt Assistant, Qt Linguistic, and multiple versions of Qt QDBusViewer. This is messy and non-ideal. These apps come from the `qttools` Qt repo, which also includes `qdbus`. And `kinfocenter` uses the `qdbus` command to get KWin support info:
```
$ grep -r qdbus
Modules/kwinsupportinfo/main.cpp:22: auto outputContext = new CommandOutputContext(QLibraryInfo::location(QLibraryInfo::BinariesPath) + QStringLiteral("/qdbus"),
Modules/kwinsupportinfo/kcm_kwinsupportinfo.json.in:79: "TryExec": "@QtBinariesDir@/qdbus",
```
So because `kinfocenter` uses `qdbus`, distros that don't split it into its own package will as a result install `qttools` and pull in the unrelated dev apps.
We should try to replace this usage of `qdbus` so that the `qttools` repo can be optional and distros don't have to pre-install it to satisfy `kinfocenter`'s dependencies and pollute their user installs with dev apps.
Some distros split the packages such that `qdbus` can be installed on its own without pulling in these other apps, but that requires extra work from them to split up the content in the `qttools` repo, and this doesn't seem fair to them. Additionally, some distros like Arch Linux don't do this as a matter of policy and instead always follow upstream packaging.6https://invent.kde.org/plasma/plasma-desktop/-/issues/69Plasma 6 proposal: disable splash screen by default2023-05-14T19:13:48ZFushan WenPlasma 6 proposal: disable splash screen by defaultThe splash screen from ancient times was used to make people less anxious during the long period of a login process.
![图片](/uploads/d45359c740f32cb2952a9026c5ab5b74/图片.png)
But since Windows has become almost unusable with HDD, SSD is ...The splash screen from ancient times was used to make people less anxious during the long period of a login process.
![图片](/uploads/d45359c740f32cb2952a9026c5ab5b74/图片.png)
But since Windows has become almost unusable with HDD, SSD is popular nowadays. The splash screen on the contrary increases the loading time from entering password to the desktop finally being shown, brings negative performance hints about KDE Plasma. It's time to disable splash by default, and perhaps even remove it completely in Plasma 6.6https://invent.kde.org/plasma/kwin/-/issues/134reduce latency for cursor updates2023-07-26T14:11:51ZXaver Huglreduce latency for cursor updatesRight now we commit atomic commits right after rendering, and have the drm driver wait on rendering to be done. This causes two problems:
- when render time is high, we need to commit up to a full frame before the page flip. This means t...Right now we commit atomic commits right after rendering, and have the drm driver wait on rendering to be done. This causes two problems:
- when render time is high, we need to commit up to a full frame before the page flip. This means the cursor will have a lot more latency than needed
- when we miss the page flip because rendering takes too long, the cursor update is dropped as well
With a proper async update API for cursors missing in the drm API, the next best solution is to always commit right before vblank with updated cursor data, and only update the framebuffer of the primary plane if rendering is complete.6https://invent.kde.org/plasma/plasma-desktop/-/issues/67[Approved] Plasma 6 proposal: Remove or disable "Windowed widgets" by default2023-05-08T04:03:12ZJoshua Goinsjosh@redstrate.com[Approved] Plasma 6 proposal: Remove or disable "Windowed widgets" by defaultFrom https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/315, I thought about the search category "Windowed widgets" and it came to me that this might not be very useful at all. This MR was specifically removing one widget (C...From https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/315, I thought about the search category "Windowed widgets" and it came to me that this might not be very useful at all. This MR was specifically removing one widget (Calculator) from appearing in search results, so I thought maybe we should just do away with this category entirely.
Is there a use case that is fullfilled with having a windowed widget (where they were not really designed to be expanded or put inside of a window)? The one time I used the color picker in a windowed widget was painful for example, but by no fault of it's own - I don't think any widgets were designed this way. If you can think of a reason, maybe it should be disabled by default instead (or put very low in the priority list).
Edit: I just realized that it's the plasmoid's decision to be standalone, but the point still stands.6Joshua Goinsjosh@redstrate.comJoshua Goinsjosh@redstrate.comhttps://invent.kde.org/plasma/plasma-desktop/-/issues/65[Approved] Plasma 6 proposal: remove System Settings Icon view2023-09-15T13:39:24ZNate Graham[Approved] Plasma 6 proposal: remove System Settings Icon viewIt doesn't support the "Highlight changed Settings" feature or the "Quick Settings" view, both of which were major features that were well-received by users. It's unmaintained and slowly bit-rotting, like the old tree view was until we r...It doesn't support the "Highlight changed Settings" feature or the "Quick Settings" view, both of which were major features that were well-received by users. It's unmaintained and slowly bit-rotting, like the old tree view was until we removed it. And the very concept of having multiple UI styles for a settings app seems like overkill; I think it would be best if we had just one and made it really good.
@teams/vdg6Carl Schwancarl@carlschwan.euCarl Schwancarl@carlschwan.euhttps://invent.kde.org/plasma/plasma-desktop/-/issues/63[Approved] Plasma 6 proposal: delete some of the Task Switchers from kdeplasm...2024-03-01T18:08:58ZNate Graham[Approved] Plasma 6 proposal: delete some of the Task Switchers from kdeplasma-addons* Grid (Thumbnail Grid is better and doesn't take up the entire screen)
* Informative (it's the same as Compact but with less space efficiency)
* Thumbnails (it scrolls horizontally after only 5 or 6 windows, which is really awkward and ...* Grid (Thumbnail Grid is better and doesn't take up the entire screen)
* Informative (it's the same as Compact but with less space efficiency)
* Thumbnails (it scrolls horizontally after only 5 or 6 windows, which is really awkward and unpleasant; same issue as the "Breeze" sidebar style switcher)
* Small Icons (tiny icons are very hard to see and window title text is always elided into uselessness)
* Text Only (it's like Compact but worse without icons, since this loses visual scanability)
@teams/vdg @teams/usability6https://invent.kde.org/plasma/plasma-desktop/-/issues/62[Approved] Plasma 6 proposal: remove the ability to set the font DPI on Wayland2023-05-23T13:53:59ZNate Graham[Approved] Plasma 6 proposal: remove the ability to set the font DPI on WaylandPreviously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
This setting's existence contributes mightily to scaling feeling buggy ...Previously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
This setting's existence contributes mightily to scaling feeling buggy and broken, since it's yet another knob people can twist to scale the system, but they won't understand its consequences, and it will interact poorly with other scaling options also in use.
We tried to remove it before (see https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/270) for Plasma 5.21 but people complained that they were using it to work around the blurry fractional scaling, which at the time seemed reasonable, so we reverted the change (see https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/669). However that's fixed in Plasma 6, at least for Qt and SDL apps.
@teams/usability6https://invent.kde.org/plasma/plasma-desktop/-/issues/61Plasma 6 proposal: remove all existing cursor launch feedback options and jus...2023-05-06T05:43:29ZNate GrahamPlasma 6 proposal: remove all existing cursor launch feedback options and just use the standard busy cursor insteadPreviously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
"Static" isn't an animation at all and looks really weird.
"Blinking" ...Previously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
"Static" isn't an animation at all and looks really weird.
"Blinking" looks quite terrible, almost broken.
"Bouncing" (the current default setting) is polarizing, with a vocal crowd of people who really hate it.
Ultimately I think all this configurability and the code driving them is not worth the maintenance and drama. Instead, we can just use the standard pointer+spinner cursor and automatically time it out after 5 seconds. No need for any configurability here, IMO.
@teams/vdg6https://invent.kde.org/plasma/plasma-desktop/-/issues/60Plasma 6 proposal: remove per-activity power management settings KCM2023-04-05T19:22:01ZNate GrahamPlasma 6 proposal: remove per-activity power management settings KCMPreviously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
Per-activity power management settings add a full dimension of complexi...Previously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
Per-activity power management settings add a full dimension of complexity in the power management code both in terms of UI and implementation, and have few to no use cases which aren't served better by something else.
With the Activities proposals in https://invent.kde.org/plasma/kactivitymanagerd/-/issues, all Plasma settings could ultimately be made per-activity, allowing people to self-satisfy anyway.
Let's remove this KCM and its features.
@teams/usability @teams/vdg6https://invent.kde.org/plasma/plasma-desktop/-/issues/59Plasma 6 proposal: remove the ability to globally configure the icon/text vis...2023-05-06T05:42:52ZNate GrahamPlasma 6 proposal: remove the ability to globally configure the icon/text visibility on buttonsPreviously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
Similar to https://invent.kde.org/plasma/plasma-desktop/-/issues/58, th...Previously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
Similar to https://invent.kde.org/plasma/plasma-desktop/-/issues/58, this feature can't work universally. So the user changes the setting and it only affects some buttons in some apps, seeming totally random and giving the user the impression that the system is buggy and broken. Fixing it across all KDE apps would be an enormous amount of work, and even then, it wouldn't affect GTK apps, Electron apps, most other 3rd-party apps, etc. See https://bugs.kde.org/show_bug.cgi?id=462352.
It's another "broken promise" feature; let's remove it.
@teams/usability @teams/vdg6https://invent.kde.org/plasma/plasma-desktop/-/issues/58[Approved] Plasma 6 proposal: remove the ability to configure icon sizes syst...2024-03-08T16:02:38ZNate Graham[Approved] Plasma 6 proposal: remove the ability to configure icon sizes systemwide in the icons KCMPreviously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
People use this setting as a way around using the global scaling slider...Previously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
People use this setting as a way around using the global scaling slider to make things bigger or smaller, and it's the wrong way to do it. It only scales some icons in some apps, and the proportions of everything else look wrong. This is a general theme: we need to fix our own bugs, rather than offer user-configurability that lets people work around the bugs themselves, which generally causes even more bugs in the process.
This setting doesn't affect non-Qt apps, almost all of KDE's own QtQuick apps, and even random icons in QtWidgets apps. It's one of those "broken promise" features that needs to be universal to work, and because universality isn't feasible or even possible, it can't really work.
Let's remove it.
@teams/vdg @teams/usability6