DESCRIPTION Say you bind a shortcut with some id and description. In a later session, when BindShortcuts is called, this shortcut may be registered again but with a different description to before, but this is not reflected in Plasma Settings; the description stays the same as it originally was. For instance, I am currently trying to implement support for the global shortcuts portal for OBS Studio. Whenever a user creates a scene, a new shortcut needs to be created for switching to that scene. This shortcut's description will have the name of the scene attached to it. However, if the user changes the name of the scene, there is seemingly no way of changing the description without registering a brand new shortcut (with a new id), which the user will manually need to rebind themselves. There are other scenarios where a shortcut's description could change. For instance, it could change after an app update, or because the user changed their language settings. STEPS TO REPRODUCE I was using the ASHPD Demo for the GlobalShortcuts portal (for the sake of demonstration). 1. Bind a shortcut with some id and description then start a session. 2. Start a session. 3. Stop the session. 4. Change the description of the shortcut, keeping the id the same as before. 5. Start the session again. When looking in Plasma Settings, the description of the shortcut does not change to whatever you set it to in step 4; it remains as whatever you set it to in step 1. EXPECTED RESULT The description of the shortcut correspond to whatever it was last set to. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 44 KDE Plasma Version: 6.7.2 KDE Frameworks Version: 6.27.0 Qt Version: 6.11.1 ADDITIONAL INFORMATION N/A
A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/602
Git commit 0d743a716918a745e69845687e548990907e79ba by David Redondo. Committed on 15/07/2026 at 13:26. Pushed by davidre into branch 'master'. globalshortcuts: Do not register shortcuts on session creation Shortcuts should only become active when BindShortcuts is called. As a side effect fixes applications not being able to update the shortcut description as kglobalacceld only allows updating the strings in doRegister. FIXED-IN:6.7.4 M +0 -2 src/globalshortcuts.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/0d743a716918a745e69845687e548990907e79ba
Git commit 2f9ae51e29b06b2bf64f7f863a3e0b0b1d28be05 by David Redondo. Committed on 16/07/2026 at 06:49. Pushed by davidre into branch 'Plasma/6.7'. globalshortcuts: Do not register shortcuts on session creation Shortcuts should only become active when BindShortcuts is called. As a side effect fixes applications not being able to update the shortcut description as kglobalacceld only allows updating the strings in doRegister. FIXED-IN:6.7.4 (cherry picked from commit 0d743a716918a745e69845687e548990907e79ba) Co-authored-by: David Redondo <kde@david-redondo.de> M +0 -2 src/globalshortcuts.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/2f9ae51e29b06b2bf64f7f863a3e0b0b1d28be05
The change here is problematic for backwards compatibility. We just got a bug report that the shortcuts aren't bound anymore in our pre-release build that has a lot of quirks for different portals and versions. I used to use ListShortcuts to detect if I need to call BindShortcuts on Plasma so that the shortcuts are bound on app startup. If I implicitly called BindShortcuts on Plasma it would always show the shortcut binding dialog on any older Plasma release which are widely in use. Either ListShortcuts needs to return an empty list before BindShortcuts to make our behavior work on any Plasma release (and we don't have a bug in KeePassXC) or I'm using the portal the wrong way which causes BindShortcuts to always open the shortcuts dialog and there's a fix that we can apply before we ship our final release that works for any Plasma release and other portal implementations too. Any advice as I'm currently looking at the fix for this issue as causing a regression? https://github.com/keepassxreboot/keepassxc/issues/13578