SUMMARY You used to be able to assign a global shortcut that included an order of keypresses rather than modifiers being pressed at the same time as another key, but in the latest version that is no longer possible. STEPS TO REPRODUCE 1. Go into system settings' global shortcuts menu 2. Select a task and click "Add custom shortcut" 3. Press shift, release shift, and then press Z OBSERVED RESULT The shortcut is finalized immediately after you let off of the shift key, preventing you from assigning a sequential shortcut with it. EXPECTED RESULT After you let off of shift the shortcut is not finalized until after you press Z, then in order to activate the shortcut you must press shift, release, then press Z. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Latest from arch repos KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION In order to manually add a sequential shortcut you can modify .config/kglobalshortcutsrc and after the equals sign for a given action put "Shift\\, Z". For some reason in order to actually get this to apply you'll need to log out completely, log in as a different user, write the changes, then log back in. No matter what I tried I could not get it to save properly while I was still logged in, it would always get overwritten. After writing the changes with my user completey logged out however upon logging in again the shortcut works as expected.
*** This bug has been marked as a duplicate of bug 478219 ***
478219 is something else entirely
*** This bug has been marked as a duplicate of bug 480304 ***
(In reply to fanzhuyifan from comment #3) > > *** This bug has been marked as a duplicate of bug 480304 *** that still seems different. That's a feature add request whereas this was functionality that already existed in system settings before. The shortcut itself works fine, the issue is that you can no longer create them in the Shortcuts menu of System Settings. If you login as a different user and modify the kglobalshortcutsrc manually then log back in the shortcut will work as expected, you can just no longer create them from the settings window like you could before. 480304 is requesting that the existing behaviour be extended and improved (notably with regards to timeouts, "I saw KDE has some "unusual" shortcuts such as "Alt + D, E" ... they are not actually "second stroke" shortcuts in its full meaning. I.e., the timeout after Alt + D is not going. I can press Alt + D, then wait many seconds, then press E. And that shortcut will work.") whereas this is a regression in the System Settings menu that prevents users from assigning shortcuts with the existing system as-is.
(In reply to BulletproofBears from comment #4) > (In reply to fanzhuyifan from comment #3) > > > > *** This bug has been marked as a duplicate of bug 480304 *** > > that still seems different. That's a feature add request whereas this was > functionality that already existed in system settings before. The shortcut > itself works fine, the issue is that you can no longer create them in the > Shortcuts menu of System Settings. If you login as a different user and > modify the kglobalshortcutsrc manually then log back in the shortcut will > work as expected, you can just no longer create them from the settings > window like you could before. > > 480304 is requesting that the existing behaviour be extended and improved > (notably with regards to timeouts, "I saw KDE has some "unusual" shortcuts > such as "Alt + D, E" ... they are not actually "second stroke" shortcuts in > its full meaning. I.e., the timeout after Alt + D is not going. I can press > Alt + D, then wait many seconds, then press E. And that shortcut will > work.") whereas this is a regression in the System Settings menu that > prevents users from assigning shortcuts with the existing system as-is. The original reporter of BUG 480304 (Andrew Shark) was not aware that KDE already supports multi-key shortcuts. After chatting with him on the matrix channel and explaining the current situation several months back, he was pretty happy with the current planned solution of exposing that setting in system settings. Hence, I think for practical purposes BUG 480304 should be interpretted as ``expose multi-key shortcuts''. In addition, multiple bug reports asking for that has been marked as duplicates of BUG 480304. Unfortunately that require pretty big changes in the dbus api of kglobalaccel, and corresponding changes to upstream users of that api that I haven't had time to do. (e.g., see https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/105#note_887228) If anyone else is interested and motivated to do that, they are extremely welcome to. If people want enhancements to the current system (e.g., adding time outs, OSDs, etc..), IMO different bug reports should be opened, because I plan to mark to BUG 480304 as FIXED after getting https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2060 merged.
(In reply to fanzhuyifan from comment #5) > (In reply to BulletproofBears from comment #4) > > (In reply to fanzhuyifan from comment #3) > > > > > > *** This bug has been marked as a duplicate of bug 480304 *** > > > > that still seems different. That's a feature add request whereas this was > > functionality that already existed in system settings before. The shortcut > > itself works fine, the issue is that you can no longer create them in the > > Shortcuts menu of System Settings. If you login as a different user and > > modify the kglobalshortcutsrc manually then log back in the shortcut will > > work as expected, you can just no longer create them from the settings > > window like you could before. > > > > 480304 is requesting that the existing behaviour be extended and improved > > (notably with regards to timeouts, "I saw KDE has some "unusual" shortcuts > > such as "Alt + D, E" ... they are not actually "second stroke" shortcuts in > > its full meaning. I.e., the timeout after Alt + D is not going. I can press > > Alt + D, then wait many seconds, then press E. And that shortcut will > > work.") whereas this is a regression in the System Settings menu that > > prevents users from assigning shortcuts with the existing system as-is. > > The original reporter of BUG 480304 (Andrew Shark) was not aware that KDE > already supports multi-key shortcuts. After chatting with him on the matrix > channel and explaining the current situation several months back, he was > pretty happy with the current planned solution of exposing that setting in > system settings. Hence, I think for practical purposes BUG 480304 should be > interpretted as ``expose multi-key shortcuts''. In addition, multiple bug > reports asking for that has been marked as duplicates of BUG 480304. > > Unfortunately that require pretty big changes in the dbus api of > kglobalaccel, and corresponding changes to upstream users of that api that I > haven't had time to do. (e.g., see > https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/ > 105#note_887228) If anyone else is interested and motivated to do that, they > are extremely welcome to. > > If people want enhancements to the current system (e.g., adding time outs, > OSDs, etc..), IMO different bug reports should be opened, because I plan to > mark to BUG 480304 as FIXED after getting > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2060 merged. I'm not sure what you mean because this is a feature regression, not a feature request. It was possible to assign these shortcuts before from the systemsettings shortcuts menu, I know because I only found out that these shortcuts are possible because I stumbled across it in that very menu. I originally noticed the behaviour when I pressed and let-off shift accidentally when I was trying to make another shortcut and I noticed that the interface didn't show the shortcut as fully assigned yet. I've never used any third party software to make shortcuts and I didn't even know that the kglobalshortcutsrc file existed before I researched it while making this bug report so that I could have a reproducible example. I had one of these shortcuts already assigned even though I've never touched any way of adding shortcuts outside of the systemsettings menu, so even if I didn't remember first discovering the behaviour I literally couldn't have assigned my pre-existing sequential shortcut if it weren't possible in the system settings menu. If it would take such deep changes to do what you're talking about, then it has to be something else because what I'm describing was already a feature less than a year ago. If I knew the exact version I was on I'd give it for reference, but I *think* it was shortly after updating to KDE plasma 6 for whatever that's worth. (especially when it comes to things like this my memory has about three states, "yesterday", "a week ago" and "longer than a week ago") Eitherway I know for a fact that it was possible because I literally could not have the shortcut I have if it weren't since I didn't even know how to assign shortcuts anyway other than the system settings menu and I've had this shortcut for a while now. If what you're talking about would require such deep-cutting changes then it must be something else because I can say with absolute certainty this was a thing that was implemented and functional fairly recently. It sounds like you're talking about a similar but decidedely different issue, but what I'm referring to is just the ability to assign sequential shortcuts in the KDE system settings "shortcuts" submenu and I can say with absolute certainty it worked recently.
I did some searches and found confirmation, when I first discovered the feature it was july 2023, so not KDE 6. I sent an image of it to a friend to show them the feature after I found it. https://postimg.cc/Wd0b1sLg I'm running off the arch repos so whatever version it was must have been <1 month old as of july 2023 for me to discover it then.