Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-08-25T23:44:36Zhttps://invent.kde.org/plasma/plasma-desktop/-/issues/83[Approved] Plasma 6 Proposal: remove the "disable tooltips" option2023-08-25T23:44:36ZNate Graham[Approved] Plasma 6 Proposal: remove the "disable tooltips" optionThe General Behavior KCM has an option in it to disable tooltips. This option only affects Plasma. But it lives in a KCM that is implied to be global in scope, as everything else in the KCM is either global in scope or at least affecting...The General Behavior KCM has an option in it to disable tooltips. This option only affects Plasma. But it lives in a KCM that is implied to be global in scope, as everything else in the KCM is either global in scope or at least affecting all KDE software, with many affecting KDE and GTK software. This makes the tooltip setting a ["broken promise"](https://community.kde.org/Get_Involved/Design/Lessons_Learned#%22Broken_promise%22_global_options) option. Many years ago, the promise was slightly less broken because this KCM only contained Plasma-specific options (even though that was always implicit, and never stated anywhere). Over the years we added things to it and made it a de facto "generic global options" KCM, making the promise more broken.
I can see the following available options:
1. Clarify the scope of the option by changing the text and/or using a ContextualHelpButton or something
2. Move the option to somewhere that is clearly Plasma-specific
3. Port all KDE apps to respect the option, or even upstream it to Qt so that all Qt apps can respect it
4. Delete the option
---
\#1 would probably be the simplest and easiest solution.
\#2 would be more challenging as we don't really have a settings UI that is clearly all about Plasma-global options which don't affect apps.
\#3 would probably be the most useful solution, at the cost of being potentially be a very large amount of work for questionable gains--and even then, it would still not affect GTK apps, Electron apps, etc.
\#4 might make the most sense if we can't do option #3. I don't really see the value of being able to turn off tooltips only in Plasma; if you don't like tooltips, wouldn't you want to turn them off everywhere? And if you can't, would you be satisfied if you can only settle for turning them off in Plasma?
Thoughts?
@teams/usability @teams/vdg6https://invent.kde.org/plasma/kwin/-/issues/148Power saving with variable refresh rate2023-12-21T18:53:57ZXaver HuglPower saving with variable refresh rateIn many cases, driving a high resolution and/or high refresh rate display requires the GPU to keep VRAM clocks high, which uses a lot of power. With VRR, we can reduce the refresh rate when appropriate to reduce that power usage.
This i...In many cases, driving a high resolution and/or high refresh rate display requires the GPU to keep VRAM clocks high, which uses a lot of power. With VRR, we can reduce the refresh rate when appropriate to reduce that power usage.
This is a long term goal, as the kernel API isn't currently well suited for this purpose: We have one property that toggles whether or not the kernel changes the refresh rate to the rate at which KWin commits new frames, and that's it. This is problematic, as in normal desktop operations KWin submits buffers in irregular patterns, causing the refresh rate to change rapidly, and thus causing visible flicker on many displays.
Some possibilities of implementing this would be:
- (obviously) add a kernel API allowing us to set any refresh rate we want, or to otherwise limit the rate at which the refresh rate changes to eliminate flicker. With the rate at which the drm API evolves I'm not optimistic about this, but maybe worth a try
- we could enable VRR whenever we're not updating anything. This has the drawback that we're drastically changing the refresh rate, causing a moment of brightness change, but it's not that noticeable if it doesn't happen often
- recently amdgpu has added VRR modes. These are a few special modes that can be switched to without doing a modeset. Which modes can do this can be figured out by doing atomic tests, so it would be possible to switch to a lower refresh rate mode while KWin is committing fewer frames. As a downside, this is still rapidly changing the refresh rate, so the same caveat as with the option above applies
- with !3828 and some additional work, it may be possible to use the commit thread to do atomic commits at a very stable rate, allowing us to emulate any refresh rate + limited rate of change thereof we want. It may also require actually triggering page flips though, so we'd need at least two identical buffers to flip between... needs to be tested and evaluated if it's worth the complexity.https://invent.kde.org/plasma/kwin/-/issues/124Triple buffering2023-12-26T02:19:34ZVlad ZahorodniiTriple bufferingAt the moment, `kwin_wayland` always uses double-buffering. It works great for our needs - avoid tearing and keep latency at reasonable levels. However, this is not optimal for low-end hardware, e.g. non-gaming laptops. For that kind of ...At the moment, `kwin_wayland` always uses double-buffering. It works great for our needs - avoid tearing and keep latency at reasonable levels. However, this is not optimal for low-end hardware, e.g. non-gaming laptops. For that kind of hardware, `kwin_wayland` should fallback to triple buffering to keep frame rate at the same level as `kwin_x11`.
`kwin_x11` has a heuristic that forces triple buffering operation mode when it discovers an intel gpu. If it's an amd gpu, `kwin_x11` will use double-buffering. This lets us to have both: optimize latency when running with more powerful hardware and have more smoother animations when running on a laptop.
# State of the things
## X11
Mesa has an internal queue of buffers that KWin has rendered to. Some time before vblank, one buffer gets taken out of the queue for presentation, and the buffer used for presentation before becomes available again for KWin to render with. So this increases latency by n frames (probably one or two), but it also gives the GPU more time to finish rendering.
## Wayland
- `kwin_wayland`: always uses double-buffering
- `mutter`: always uses double-buffering, but there's wip patch to add support for triple buffering https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441
- `wlroots`-based compositors: use double-buffering too
# KMS API considerations
At the moment, once a page flip is scheduled, the compositor cannot schedule another one or replace existing one.
`FIFO` mode can be implemented with the existing API in the userspace by making the compositor queue pending updates and dequeue them in the page flip handler.
`MAILBOX` mode can be implemented by amending previous atomic commit. There are two problems with this solution: the necessary API is not present yet and MAILBOX can't be properly implemented in the userspace. For example, what if the compositor decides to amend an atomic commit when vblank happens? Buffer switching must happen in the vblank handler in the driver.
In both cases, the compositor would need some careful state tracking changes, particularly when using output layers or moving the cursor.
The compositor side can be simplified and made less error prone by specifying the presentation mode to the DRM driver and letting it to take care of `FIFO` or `MAILBOX` presentation mode.
_zzag: The definitive position of the DRM developers on this matter is unknown to us yet. We need to ask them what they think about it._
# Other potential ways to improve smoothness of animations on Wayland
Besides employing triple buffering, it's also worth considering introducing a special animation mode during which GPU's core and memory clock frequencies are boosted.
_zzag: Needs somebody to do proper research in this area. Particularly, power usage and whether it actually helps to solve the problem._6https://invent.kde.org/plasma/latte-dock/-/issues/123Fullscreen window going behind Latte-panel2023-12-18T22:10:05ZSparsa RoychowdhuryFullscreen window going behind Latte-panelI am using latte-dock and latte-panel (latte-dock-git) for my dual monitor setup with KDE plasma 5.26.2. When I use the global menu, and windows button extensions when I maximize a window, it should hide the title bar. It is hiding the t...I am using latte-dock and latte-panel (latte-dock-git) for my dual monitor setup with KDE plasma 5.26.2. When I use the global menu, and windows button extensions when I maximize a window, it should hide the title bar. It is hiding the title bar, but the window is going behind the latte panel which was not expected. I came up with the bug https://bugs.kde.org/show_bug.cgi?id=447595 which is very similar to what I am facing, but it might be resolved in the .10 branch, not in the master branch or latte-doc-git branch. Can you look into this matter and confirm? I am on Wayland.https://invent.kde.org/plasma/plasma-mobile/-/issues/147[widgets/notifications] Implement popup notifications2024-03-21T18:21:26ZDevin Lin[widgets/notifications] Implement popup notificationsThe last major thing to implement with the notifications widget are "popup" notifications, which are currently still provided by the desktop notification plasmoid. This would then allow us to remove the desktop notification plasmoid enti...The last major thing to implement with the notifications widget are "popup" notifications, which are currently still provided by the desktop notification plasmoid. This would then allow us to remove the desktop notification plasmoid entirely from the panel containment, reducing memory usage of the shell.6.1Yari Pollaskilvingr@gmail.comYari Pollaskilvingr@gmail.comhttps://invent.kde.org/plasma/breeze/-/issues/9Blue Ocean - inconsistencies with checkboxes and dropdown highlights2023-10-17T16:16:45ZBharadwaj RajuBlue Ocean - inconsistencies with checkboxes and dropdown highlights1. Checkbox when checked and disabled loses its frame:
![breeze-ocean-disabled-checkbox-crop](/uploads/4ef5948b29f987b25099075f0ec68207/breeze-ocean-disabled-checkbox-crop.png)
2. Highlight on dropdowns looks different from other menus...1. Checkbox when checked and disabled loses its frame:
![breeze-ocean-disabled-checkbox-crop](/uploads/4ef5948b29f987b25099075f0ec68207/breeze-ocean-disabled-checkbox-crop.png)
2. Highlight on dropdowns looks different from other menus (padding):
![breeze-ocean-dropdown-padding](/uploads/cdcbb78d16b1267afc93b47764cc3fa5/breeze-ocean-dropdown-padding.png)https://invent.kde.org/plasma/plasma-mobile/-/issues/71[logout] It isn't obvious when the power button should be released when tryin...2024-03-16T17:17:19ZBart Ribbers[logout] It isn't obvious when the power button should be released when trying to get to the poweroff menuCurrently the poweroff menu appears when the power button is being released after holding it for some times. However, there is no indication when enough time has passed and you can release the button. This way you might hold the button t...Currently the poweroff menu appears when the power button is being released after holding it for some times. However, there is no indication when enough time has passed and you can release the button. This way you might hold the button till you're force shutting down the phone, which is unexpected.
Instead the menu should show when enough time has passed, no matter if the power button is still being held or not.https://invent.kde.org/plasma/kwin/-/issues/210RFE: use systemd FD store for kwin_wayland_wrapper2024-03-13T13:05:40ZMike Yuanme@yhndnzj.comRFE: use systemd FD store for kwin_wayland_wrapperCurrently, KWin uses its own wrapper to hold wayland FD and track exit status. This means `systemctl --user restart plasma-kwin_wayland.service` won't be handled properly.
systemd has a [FD store](https://systemd.io/FILE_DESCRIPTOR_STOR...Currently, KWin uses its own wrapper to hold wayland FD and track exit status. This means `systemctl --user restart plasma-kwin_wayland.service` won't be handled properly.
systemd has a [FD store](https://systemd.io/FILE_DESCRIPTOR_STORE/) mechanism where the service main process is able to upload arbitrary FDs to the service manager, so that they can survive restart. It should be able to replace the wrapper's process tracking part, as described below:
Initial run:
1. wrapper sets up (X)wayland sockets and basic env
2. wrapper uploads the FDs to fdstore, including a memfd that records socket names (or a `/etc/environment`-style env file)
3. wrapper _execve()_ KWin, i.e. replaces itself
When KWin crashes, systemd is responsible for checking the exit status and restarting the wrapper. The new wrapper receives FDs passed by service manager and deserializes state from memfd. It then replaces itself with KWin, as with 3.
The crash counting can be implemented by quering for `NRestarts` dbus property.
This enables KWin to survive `systemctl restart`. Plus, by delegating process tracking to the service manager, the unit status correctly reflects the status of KWin.
To make sure that the stop of `plasma-kwin_wayland.service` won't bring down dependents, `RestartMode=direct` can be used if desired.6.1https://invent.kde.org/plasma/plasma-desktop/-/issues/117Single unified Mouse & Touchpad KCM2024-03-15T18:16:24ZJakob PetsovitsSingle unified Mouse & Touchpad KCMThe plan in https://invent.kde.org/plasma/systemsettings/-/issues/15 is to have a "Mouse & Touchpad" KCM, rather than a "Mouse & Touchpad" category. In addition to merging the existing "Mouse" and "Touchpad" KCMs, it would also absorb th...The plan in https://invent.kde.org/plasma/systemsettings/-/issues/15 is to have a "Mouse & Touchpad" KCM, rather than a "Mouse & Touchpad" category. In addition to merging the existing "Mouse" and "Touchpad" KCMs, it would also absorb the majority of the "General Behavior" KCM (which provide options that apply to both). The "Screen Edges" KCM would be a sub-page within the top-level "Mouse & Touchpad" KCM.
This would have been a ton of work pre-6.0, but with only libinput-based backends remaining as a result of #79, it's much more feasible now. Rough plan of action to make this happen:
1. Remove the now unnecessary QtWidgets middle man in `kcm_mouse` and `kcm_touchpad`, migrate both to `KQuickConfigModule` and `KCModuleData`.
* This might eventually help to enable highlighting for modified settings, but will need more changes.
* Consider expanding libkwindevices to also support mouse and touchpad properties, and switching to that for the `deviceModel` used by QML.
2. Move `kcm_mouse` into `kcm_touchpad`, or the other way round, with as few code changes as possible.
* Use `NavigationTabBar` (like in PowerDevil's KCM) to switch between mouse and touchpad settings, embed the existing QML KCMs as respective tab contents.
* Make sure to involve localization teams for string change considerations.
3. Move the appropriate settings from "General Behavior" (a.k.a. `kcm_workspace`, kcms/workspaceoptions) as a third tab (but first in tab order) into "Mouse & Trackpad".
4. Move any remaining settings out of "General Behavior" and kill that KCM.
5. Figure out how to embed "Screen Edges" (a.k.a. `kcm_kwinscreenedges`) into "Mouse & Touchpad" as a sub-page, even though it lives (for now?) in KWin.
6. Clean up code along the way where necessary. Consider renaming the KCM to e.g. `kcm_mouse_touchpad` or `kcm_pointerinput`.
MRs:
* !2067
* !2082
* !2122
* more to come6.1Jakob PetsovitsJakob Petsovitshttps://invent.kde.org/plasma/kwin/-/issues/206Architecture discussion for brightness control in KWin2024-03-20T16:01:49ZAnurag ThakurArchitecture discussion for brightness control in KWinAs part of my SoK project, I am creating this issue to discuss the proposed architecture for implementing brightness control in KWin
## Current Status
The current architecture looks like this:
```mermaid
graph TB
Action -- "DBus" -->...As part of my SoK project, I am creating this issue to discuss the proposed architecture for implementing brightness control in KWin
## Current Status
The current architecture looks like this:
```mermaid
graph TB
Action -- "DBus" --> Kact
Enum -- "DBus" --> plasma-workspace/applets/brightness
subgraph plasma-workspace/applets/brightness
Action[User Action]
end
subgraph powerdevil/daemon
Kact("KAuth Action (backlightbrightness.cpp)")
Enum("Screen Enumeration (backlighthelper_linux.cpp)")
end
```
## Proposals
There are a few different ways we could implement brightness control in KWin:
### Wayland only (1)
If X11 support can be dropped, we could move the brightness handling code to kwin completely. the architecture could look like this:
```mermaid
graph TB
Action -- "DBus/Wayland API" --> HDR
Enum -- "DBus/Wayland API" --> plasma-workspace/applets/brightness
HDR --> Kact
subgraph plasma-workspace/applets/brightness
Action[User Action]
end
subgraph kwin/new_code
HDR("HDR handling")
Kact("KAuth/logind/sysfs call")
Enum("Screen Enumeration")
end
```
#### Benefits
- Simple architecture
- No code duplication
#### Drawbacks
- No X11 support
- More code changes required
### Wayland + X11 (2)
If X11 support needs to be retained, we need to support the scenario where a different window manager is used, so brightness control can't depend on KWin. Xaver proposed that we use the existing backlight helper from powerdevil and use a new wayland protocol for communication between kwin and powerdevil as DBus may not be responsive enough.
The architecture could look like this:
```mermaid
graph TB
Action -- "DBus" --> Kact
Enum -- "DBus" --> plasma-workspace/applets/brightness
Kact -- "Yes\n\nWayland Protocol" --> HDR
Kact -- "No (X11)" --> X11
HDR -- "Wayland Protocol" --> Help
subgraph plasma-workspace/applets/brightness
Action[User Action]
end
subgraph powerdevil/daemon
Kact{"Kwin present?"}
Enum("Screen Enumeration (backlighthelper_linux.cpp)")
X11("Existing code")
Help("Backlight Helper")
end
subgraph Kwin
HDR("HDR etc. handling")
end
```
#### Benefits
- Less code changes required
- Support for X11 retained
#### Drawbacks
- Complicated architecture
- Possible performance penalty
### Wayland + X11 (3)
Alternatively, KWin can provide the DBus interface for the brightness applet on wayland and powerdevil can continue to provide it on X11.
```mermaid
graph TB
Action -- "DBus" --> Chk
Chk -- "Wayland" --> Kwin
Chk -- "X11" --> Control
Kwin --> ncnt
Enum -- "DBus (X11)" --> plasma-workspace/applets/brightness
Enum2 -- "DBus (Wayland)" --> plasma-workspace/applets/brightness
subgraph plasma-workspace/applets/brightness
Action[User Action]
Chk{"Session Type"}
end
subgraph kwin
Kwin("DBus API provider")
ncnt("HDR handling + backlight control")
Enum2("Screen Enumeration")
end
subgraph powerdevil
Control("Existing control")
Enum("Screen Enumeration")
end
```
#### Benefits
- Basically (1) with X11 support retained
- Kwin code can be improved independently of powerdevil and X11
- Later if X11 support is dropped, it would become the same as (1)
#### Drawbacks
- Slight code duplication
- More code changes required
Please share your insights and mention if I missed/misunderstood anything.https://invent.kde.org/plasma/kwin/-/issues/194VRR improvements2024-03-09T00:19:45ZXaver HuglVRR improvementsThis is just a list of issues and plans to summarize the information spread around elsewhere.
# workarounds
- [ ] when the refresh rate isn't stable, many screens flicker in brightness
- [ ] we could limit the refresh rate change in ...This is just a list of issues and plans to summarize the information spread around elsewhere.
# workarounds
- [ ] when the refresh rate isn't stable, many screens flicker in brightness
- [ ] we could limit the refresh rate change in the KMS thread (#174)
- [ ] LFC throws a wrench into the above, as the kernel will be doubling the refresh rate once it falls below some minimum. So we'll have to do LFC ourselves, and ideally get a kernel API to disable its LFC handling
- [x] In absence of our own LFC implementation, a minimum refresh rate would be desired, to prevent the kernel from going too crazy with LFC at low refresh rates
- [ ] We could also detect if the refresh rate is reasonably stable or not, and disable VRR if it isn't, which mostly circumvents the LFC issue and should be easier to do for Plasma 6.0
- [x] when we commit a cursor-plane-only update, amdgpu doesn't update the FreeSync refresh rate: https://gitlab.freedesktop.org/drm/amd/-/issues/3034. I'll try to fix it again but depending on how long that takes, kernel release schedules etc we might have to ship a workaround for Plasma 6.0 - which would be to just always send a primary plane "update" with `SRC_X = 0`
- [ ] we should keep `VRR_ENABLED` set to 1 even if the vrr policy is set to automatic and no window is fullscreen, because HDMI is stupid: https://gitlab.freedesktop.org/drm/amd/-/issues/2200
# Improvements
- [ ] we should use VRR to save power when displays don't have anything (or only very little) going on (#148)
- [x] when a software cursor gets moved around on top of a window updating with a reasonable refresh rate, the cursor shouldn't take over the refresh rate
- [ ] when a hardware cursor gets moved on top of a window updating with a reasonable refrsh rate, the cursor shouldn't take over the refresh rate. https://gitlab.freedesktop.org/drm/amd/-/issues/2186 causes problems for that, so doing that may require forcing a software cursor with VRR on AMD... (#85)
- [x] in `Always` mode, when the focused window has a reasonable and stable refresh rate, enable VRR even in windowed mode and restrict repaint scheduling to that window. If that works well and the brightness flicker problem is solved or worked around well enough, get rid of the `Automatic` option and make VRR just a toggle
- [ ] add an effect that shows whether or not VRR is active, and at what refresh rate it's running, without scheduling repaints itselfhttps://invent.kde.org/plasma/breeze/-/issues/19Followup new breeze frameless style2024-02-29T23:56:21ZCarl Schwancarl@carlschwan.euFollowup new breeze frameless style- [ ] Investigate RTL
- [ ] Investigate bottom tabbar
- Merge support in frameworks
- [x] KMultiTabBar https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/208
- Merge support for apps
- [ ] Okular https://invent.kde.org...- [ ] Investigate RTL
- [ ] Investigate bottom tabbar
- Merge support in frameworks
- [x] KMultiTabBar https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/208
- Merge support for apps
- [ ] Okular https://invent.kde.org/graphics/okular/-/merge_requests/812
- [x] Dolphin https://invent.kde.org/system/dolphin/-/merge_requests/600
- [ ] Kdevelop https://invent.kde.org/plasma/breeze/-/merge_requests/342#note_800655
- [x] Kate https://invent.kde.org/utilities/kate/-/merge_requests/1286
- [x] KMail https://invent.kde.org/pim/messagelib/-/commit/bfafeac813017b51cf27814b0e32b21ef8fb280b
- [ ] ...Carl Schwancarl@carlschwan.euCarl Schwancarl@carlschwan.eu2023-11-30https://invent.kde.org/plasma/powerdevil/-/issues/31Support alternative(s) to power-profile-daemon2024-01-07T05:14:25ZJakob PetsovitsSupport alternative(s) to power-profile-daemon[IBM / Red Hat decided to discontinue development of power-profiles-daemon](https://www.hadess.net/2023/08/new-responsibilities.html) and therefore [fd.o marks the repository as "archived"](https://gitlab.freedesktop.org/hadess/power-pro...[IBM / Red Hat decided to discontinue development of power-profiles-daemon](https://www.hadess.net/2023/08/new-responsibilities.html) and therefore [fd.o marks the repository as "archived"](https://gitlab.freedesktop.org/hadess/power-profiles-daemon). Presumably Fedora will stop shipping it before long and [replace it with TuneD](https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon).
[TuneD](https://github.com/redhat-performance/tuned) generally has a customizable set of power profiles that can be much more extensive than the three hardcoded profiles that power-profile-daemon offers/offered. In the case of RHEL, this means [a set of 15 or so profiles](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/getting-started-with-tuned_monitoring-and-managing-system-status-and-performance#tuned-profiles-distributed-with-rhel_getting-started-with-tuned), most of which are optimized for particular server loads. There is the standard `powersave` profile but also three different kinds of "performance" profiles, as well as a `desktop` profile to improve on `balanced` which is still a thing here. I'm not sure if we can even rely on any particular profiles being the same across distros. In a nutshell, things could get less one-dimensional compared to the simple three-stop slider that we're currently using.
Of course, there are still other power profile solutions out there, like good ol' [TLP](https://linrunner.de/tlp/) and custom profile modding à la #26. Nothing says that TuneD necessarily has any claim to power profile supremacy, other than Red Hat's pretty good track record at popularizing system infrastructure. I don't even have the faintest idea of what FreeBSD people are looking at (perhaps a question for @adridg).
Either way, it looks like we'll need a plan for expanding power profile support beyond just power-profiles-daemon.
(CC @nclarius in particular, given that you put a lot of work into the Battery & Brightness applet that uses the three-way slider.)https://invent.kde.org/plasma/krdp/-/issues/12Exposecthis via a GUI somewhere2024-02-19T16:58:04ZNate GrahamExposecthis via a GUI somewhereWe should consider letting the user turn on an RDP server via an easy GUI method. Maybe a new "Screen sharing" KCM or even a generic "Sharing" KCM that would live in System Settings in the "Security & Privacy" section?We should consider letting the user turn on an RDP server via an easy GUI method. Maybe a new "Screen sharing" KCM or even a generic "Sharing" KCM that would live in System Settings in the "Security & Privacy" section?https://invent.kde.org/plasma/plasma-workspace/-/issues/85Port applets' custom CompactRepresentations to the basic/default one as much ...2024-01-23T22:01:34ZNate GrahamPort applets' custom CompactRepresentations to the basic/default one as much as possible## Synopsis
Currently most applets define a custom CompactRepresentation rather than using the basic/default one that lives at https://invent.kde.org/plasma/plasma-desktop/-/blob/master/desktoppackage/contents/applet/DefaultCompactRepre...## Synopsis
Currently most applets define a custom CompactRepresentation rather than using the basic/default one that lives at https://invent.kde.org/plasma/plasma-desktop/-/blob/master/desktoppackage/contents/applet/DefaultCompactRepresentation.qml. This is because it's very limited, offering only a simple icon that opens the FullRepresentation when clicked.
Some applets have very complex CompactRepresentations, but many do not, only doing one or two things different from what the basic one offers. When such applets define a custom CompactRepresentation that's 99% identical to the basic one, the result is extra boilerplate code that increases bugginess and inconsistency. Let's try to port them the basic CompactRepresentation as much as we can, adding features as needed so that it can serve more use cases.
## Applets that can be ported right now because the default CompactRepresentation is fine
- Device Notifier: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3137
- Touchpad: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1637
- Kicker (maybe/probably; need to work through the complex `isDash` code and maybe just get rid of all of it)
## Applets that can only be ported once the default CompactRepresentation gains features
Not all applets can be ported due to the complexity of their custom CompactRepresentations, but many can. I found 12 that need only minimal functionality added to the default CompactRepresentation before they can be ported. Some features are rather common.
X = can be ported once these features are added
O = still needs custom code for other things, but would benefit from the centralized features anyway
This table is ordered by priority, e.g. which features we should add first that will do the most good:
| Feature | Application Menu | Audio | Battery | Bluetooth | Brightness | Calendar | Folder | Lock Keys | Kickoff | Networks | Sticky Notes | Trash | Web Browser | Weather | Window List |
|---------|------------------|-------|---------|-----------|------------|----------|--------|-----------|---------|----------|--------------|-------|-------------|---------|-------------|
| Optional ability to show text below or beside icon when there's space (e.g. when not in system tray) | | | O | | | | | | X | | | X | | X | X |
| Optional ability to define a custom drop handler | | | | | | | X | | X | | | X | | | |
| Optional middle-click actions | | X | O | X | O | | | | | X | | | | | |
| Optional ability to open FullRepresentation on drag hover | | | | | | | X | | X | | X | | | | |
| Optional ability to show overlay items on top of icon | | | O | | | X | | | | | | | | X | |
| Optional ability to mark icon as disabled | X | | | | | | | X | | | | | | | |
| Optional scroll actions | | X | O | | O | | | | | | | | | | |
| Ability to load images, not just icons | | | | | | | | | | | | | X | | |
## Merge requests for features added to the default CompactRepresentation:
- Key handling and accessibility: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/16386https://invent.kde.org/plasma/plasma-workspace/-/issues/72Audit which KDED services make sense to be user-disable-able2023-05-31T22:02:03ZNate GrahamAudit which KDED services make sense to be user-disable-ableSome KDED services are user disable-able, and some are not.
A lot of the ones that are IMO don't really make sense to disable, especially ones that come from a package you can simply uninstall if you don't want to use that functionalit...Some KDED services are user disable-able, and some are not.
A lot of the ones that are IMO don't really make sense to disable, especially ones that come from a package you can simply uninstall if you don't want to use that functionality, and where the provided functionality is critical such that major parts of the system stop working when they're disabled. Examples would be kscreen, kde-gtk-config, and bluedevil.
Others make no sense to be disable-able at all, such as the appmenu and vaults modules.These one should be auto-loaded when in use, and never loaded otherwise.
Others probably don't even need to *be* a KDED service, like the thing to handle Ctrl+Esc to launch the mini ksysguard. This can just be a global shortcut.
I bring this up because we've had bug reports that were caused by users disabling KDED modules to work around bugs and forgetting to turn them back on, or just doing it because they didn't understand what they were doing and then something broke.
We should audit with KDED modules actually make sense for the user to be able to disable.
@teams/usabilityhttps://invent.kde.org/plasma/plasma-desktop/-/issues/88Plasma 6 proposal: use mobile form in kcms2023-06-09T13:44:07ZCarl Schwancarl@carlschwan.euPlasma 6 proposal: use mobile form in kcmsCurrently, all the kcms coming from plasma desktop in plasma mobile are almost unusable on the phone.
There are three ways to fix it:
1. Use MobileForm (renamed to something else) everywhere. This is controversial as the layout is less...Currently, all the kcms coming from plasma desktop in plasma mobile are almost unusable on the phone.
There are three ways to fix it:
1. Use MobileForm (renamed to something else) everywhere. This is controversial as the layout is less space efficient. But this is that was done in all the other desktop operating systems (windows, macos and gnome).
2. Duplicate kcms UI code so that there is a version for mobile and a version for desktop. A bit more work but every users is happy. Generally, all the logic should be in c++ anyway, so the code duplication would be only in the UI. This is already done for the network kcm.
3. Make `Kirigami.FormLayout` work better on mobile by using the same layout as `MobileForm`. The issue is that the API are quite different and this would be very hard to implement without compromising on usability on either desktop or mobile.
I'm in favor of either 1 or 2.https://invent.kde.org/plasma/plasma-desktop/-/issues/85Plasma 6 Proposal: Rethink lookandfeel / desktop package2023-05-06T09:08:14ZDavid EdmundsonPlasma 6 Proposal: Rethink lookandfeel / desktop packageOur lookandfeel story has got a bit confusing over time.
It's simultaneously bundles of sometimes complex QML code for key Plasma parts, but also a set of configuration files to provide a set of sweeping defaults.
The only argument is ...Our lookandfeel story has got a bit confusing over time.
It's simultaneously bundles of sometimes complex QML code for key Plasma parts, but also a set of configuration files to provide a set of sweeping defaults.
The only argument is that it can bundle everything together, but it fails at doing that: The more popular global themes on store.kde.org have repos where lnf is shipped along with a bunch of other folders: https://github.com/EliverLara/Sweet/tree/nova/kde https://github.com/vinceliuice/ChromeOS-kde of things that can't be in the lnf.
Some parts; tabbox, desktopswitcher, splash allows you to select which "look and feel package" to use to provide the relevant UI. But there's no KCM to choose an OSD.
----
Desktop package is also unclear:
Why is the activity switcher in the "desktoppackage" but "desktop switcher" in the LNF? The breeze style is intended to look similar, but only one will change.
Is the plasma layout in both?
----
Having a frozen API for core plasma parts has been problematic. We've left questionable code for years for API reasons, and it's prevented progress; especially in the parts where it's more about the logic like the lockscreen.
It's a lot of pain points for something really not well documented, and therefore unused.
---
I haven't written a proposal, because an open ended discussion is probably more useful.https://invent.kde.org/plasma/plasma-workspace/-/issues/67Save more formats in clipboard history2023-04-28T14:46:02ZFushan WenSave more formats in clipboard historyDitto is a clipboard manager on Windows. The database used in Ditto contains 2 tables, and I think some fields will also be useful for klipper in regards of both performance and usability.
| Main | Data |
|---------...Ditto is a clipboard manager on Windows. The database used in Ditto contains 2 tables, and I think some fields will also be useful for klipper in regards of both performance and usability.
| Main | Data |
|----------------|-----------------|
|ID|ID|
| CRC (used to find duplicate) | ClipBoardFormat (mimetype) |
| Date | oData (binary data) |
| Text | |
| DontAutoDelete (starred) | |
| clipOrder | |
|stickyClipOrder||
The "Main" table is used to store clips. Each clip in the table has a unique CRC which is generated from all formats, and the order is saved in a separate column. In the "Data" table, an ID can be mapped to multiple records, and each record has a different format. The main advantages are:
- The structure allows the frontend to list clips quickly by only reading the "Main" table, and the "Data" table is read only when details should be shown, so users can save more images in klipper with a lower memory footprint.
- More formats like HTML rich text can also be saved in the history, like Windows clipboard history already does.
- Flexible to add more features like "sticky clip", sorting clips by date, and a klipper runner.
To achieve this goal, klipper will need to:
- [ ] Port to SQLite and use the new database
- [ ] Convert the current database
- [ ] lazily load clips on startup
- [ ] Port the search field to using SQL query instead of filtering in a model6https://invent.kde.org/plasma/plasma-desktop/-/issues/79Split libinput and legacy Mouse and Touchpad KCMs2024-02-23T21:09:13ZNicolas FellaSplit libinput and legacy Mouse and Touchpad KCMsThe mouse and touchpad KCMs currently support three different "platforms": KWin Wayland Libinput, X11 Libinput, X11 Synaptics/XLib.
Wayland Libinput and X11 Libinput share mostly the same UI, which is using QML. However the Synaptics UI...The mouse and touchpad KCMs currently support three different "platforms": KWin Wayland Libinput, X11 Libinput, X11 Synaptics/XLib.
Wayland Libinput and X11 Libinput share mostly the same UI, which is using QML. However the Synaptics UI is completely different and using Widgets.
Supporting all of that from the same KCMs makes them massively complex. They have internal backend systems and the KCM is a hybrid of QML and widgets, with all the challenges that brings.
This is not sustainable. We should split the KCMs into a Libinput variant and a legacy variant.
The challenge here is that the current thing handles switching between libinput and legacy at runtime. Would it be fine if it was a compile-time option?