Not sure which section this belongs to. kglobalaccel 6.19.0 was updated on 2025-10-13 on my system, but this issue just occurred today on the 2025-10-24 after updating Plasma and all its dependencies to 6.5.0, so I don't think this is KDE frameworks related. SUMMARY I have bound my "Volume up" and "Volume down" keys in the "Keyboard -> Shortcuts" settings menu to "Applications -> Clementine -> {In,De}crease Volume". This has been working perfectly fine until today. Before Plasma 6.5.0, I was able to hold down the buttons, but now on 6.5.0 it only works once, meaning I have to repeatedly press the buttons to increase or decrease the music player's volume for more than one step. Clementine was not updated on my system. KWin's debug console properly shows all the `Key_VolumeUp` and `Key_VolumeDown` `KeyPress` events while holding the keys and a single `KeyRelease` event at the end once released. Could this issue be caused by a recent change that tried to prevent shortcut actions to be spammed if the user accidentally kept pressing the keys for too long? That would of course make sense for certain things such as Meta+E for opening Dolphin for example (don't know if this was the case previously), but here in this situation it's complete nonsense. The title I've chosen for this report is specific to my case, but it's possible that this affects all kinds of shortcut configs. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.5.0 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0
Works for me. Can you reproduce the issue in a new clean user account on the same computer?
(In reply to Nate Graham from comment #1) > Works for me. Can you reproduce the issue in a new clean user account on the same computer? I can test this later when I have the time. Please be aware that I am talking about the "Applications -> Clementine -> {In,De}crease Volume" bindings. I am NOT talking about the general "Audio Volume -> {In,De}crease Volume" bindings which affect the default audio device's volume. This is working as expected and keys can be kept pressed, but this isn't what I'm interested in, because my shortcuts are supposed to only affect my music player and nothing else. This is why I believe that something must've changed for application-bindings (or non-specific types of bindings) where it's *usually* not expected for shortcuts to be kept pressed, to avoid unintentional multiple event triggers (like the Meta+E example).
Oh! My mistake. We did change global shortcut behavior recently, but I was under the impression that key repeat was still on by default.
Created attachment 186144 [details] video demonstration using new user account Here's a video demonstration of the issue after creating a new user account and only configuring the screen layout and audio devices, launching Clementine and OBS, and setting the desired Clementine shortcuts. You can see the KeyPress and KeyRelease events in the KWin debug console. First, the non-repeatable application shortcuts. After that, the global volume shortcuts, working as intended. And last the application shortcuts again.
I've just had a cursory look at Clementime's shortcut code. I'm sorry to say that I'm responsible for this bug... :( We needed to ensure kwin wouldn't flash the screen constantly when using certain global shortcuts. At the time, kglobalaccel didn't treat initial key presses differently from key repeat, which meant I couldn't use Qt's API to disable key repeat in things like the "Toggle Screen Color Inversion" shortcut. It looks to me like Clementime is listening to DBus signals coming directly from kglobalaccel, rather than using the QAction::triggered signal like we do with most shortcuts in kwin. As of Plasma 6.5, the DBus API for kglobalaccel was slightly changed, adding an additional "globalShortcutRepeated" signal. If applications use this API to receive shortcut events, you'd need to subscribe to the new signal if you want to get key repeat events.
Update: I kept spelling Clementine wrong and I'm embarrassed. Anyway, submitted a patch on their end. https://github.com/clementine-player/Clementine/pull/7419
Thank you very much for the quick fix and extra effort of submitting a PR to the Clementine project, Ritchie. Much appreciated! What you said about kglobalaccel's DBus signals makes sense. It's unfortunate that Clementine is a dead project and thus hasn't updated its kglobalaccel backend yet. I'm aware that a maintained fork of Clementine exists, called Strawberry. AFAIA they also have a different implementation for global shortcuts. However, I've been using custom builds of Clementine with a stripped-down config and a custom theme, and this has prevented me to migrate so far because I'm comfortable with my setup. I have applied the changes of your PR to my custom build and it's working fine. Connecting the globalShortcutRepeated DBus signal to the OnShortcutPressed handler works and makes perfect sense. This issue can therefore be closed now, but since I'm not sure if you want to keep this open for other applications which might require an update or if you want until the PR is merged, I'm leaving the status on REPORTED. Thanks again.