https://bugs.kde.org/show_bug.cgi?id=518683
Noah Davis <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Handbook opens despite |Deleting a standard |"Help" not being bound. |shortcut in system settings | |causes KStandardShortcuts | |to use a null QKeySequence | |instead of an empty list Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED CC| |[email protected] Component|General |general Product|Spectacle |frameworks-kconfig Version First|6.5.5 |6.23.0 Reported In| | Assignee|[email protected] |[email protected] Ever confirmed|0 |1 --- Comment #8 from Noah Davis <[email protected]> --- (In reply to user from comment #7) > I'm guessing because Help isn't bound the check passes because key() is 0. That's kind of amazing. 0 would have to be a Null character key ( https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block) ). Qt and libxkbcommon don't explicitly define 0x00-0x1f in their APIs, but I'm pretty sure they are supported. It seems your theory may be true because `QKeyEvent::matches()` doesn't actually check whether the key sequence is empty. I just noticed that the `initialize()` function mentioned earlier only sets a shortcut to have an empty list of key sequences if the shortcut is set to "none" in kdeglobals. Deleting a shortcut in system settings actually sets the shortcut to an empty string, which makes `initialize()` use a list containing a null character key sequence. I'll make a patch to fix KStandardShortcuts. Links to source code if you're curious and for posterity: - https://codebrowser.dev/qt6/qtbase/src/gui/kernel/qevent.cpp.html#1493 - https://codebrowser.dev/qt6/qtbase/src/gui/kernel/qkeysequence.cpp.html#868 - https://codebrowser.dev/qt6/qtbase/src/gui/kernel/qkeysequence.cpp.html#916 - https://invent.kde.org/frameworks/kconfig/-/blob/master/src/gui/kstandardshortcut.cpp?ref_type=heads#L571 -- You are receiving this mail because: You are watching all bug changes.
