| Summary: | krunner not invoked by global shortcut (changed from default) | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Mark T. Kennedy <mtk> |
| Component: | kcm_keys | Assignee: | Michael Jansen <kde> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | alexander.lohnau, fanzhuyifan, kde, nate, plasma-bugs-null, the.neophytes.logs |
| Priority: | NOR | ||
| Version First Reported In: | 5.18.5 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Mark T. Kennedy
2020-06-18 17:27:04 UTC
I am not able to reproduce this on my computer. Krunner starts fine for me using Meta-F2. Here's my system information if it helps: Operating System: Manjaro Linux KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.15.0 Kernel Version: 5.7.0-3-MANJARO >This behavior was persistently observed after using xmodmap to change my physical Alt_L key to emit the Meta_L keysym event.
So you can no longer reproduce with that step?
no, it persists across reboots. reliably. xev verifies that Meta-F2 is being generated. and krunner ignores it. if you want to explore this with me further, my time is available. and i'm old and very experienced developer. Requested information was added with comment 2; changing status for inspection. chris - what does your last comment mean? this behavior is persistent. to recap - the Alt_L physical key on my keyboard generates the Meta_L X Windows keysym. the Alt_R physical key generates the Alt_R keysym. System Settings for global shortcuts shows that invoking krunner is bound to Meta-F2 with no other binding. But typing Meta-F2 does *nothing*. If i add a shortcut binding for a bare F2 or Shift-F2 to invoke krunner, they *work*. strangely, i noticed tonight that the left and right 'Windows' keys, which i have configured to generate the X Windows keysyms Super_L and Super_R respectively, invoke krunner! yet as i said earlier, the only binding shown in System Settings is for Meta-F2. this situation is *persistent* and deterministic and repeatable. if it helps, this is the output of 'xmodmap -pm': % xmodmap -pm xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock control Control_L (0x25), Control_R (0x69) mod1 Meta_L (0x40), Meta_L (0xcd) mod2 Alt_R (0x6c) mod3 Super_L (0x85), Super_L (0xce) mod4 Hyper_L (0x42), Hyper_L (0xcf) mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb) ah, so if kwin *is* the process that owns the events that trigger krunner, then i discovered something relevant today. i was trying to invoke a gnu emacs action via Meta-<mouse drag> and instead the emacs window was selected and i was able to move it. surprised, i went to System Settings and discovered that this behavior was supposed to be on *Alt*, not *Meta*. recall that i used xmodmap to remap Alt to be Meta. so apparently kwin *ignores* xmodmap changes and doesn't use the current X server keysym. thoughts/comments? (In reply to Oussema Bouaneni from comment #1) > I am not able to reproduce this on my computer. Krunner starts fine for me > using Meta-F2. > Here's my system information if it helps: > Operating System: Manjaro Linux > KDE Plasma Version: 5.18.5 > KDE Frameworks Version: 5.70.0 > Qt Version: 5.15.0 > Kernel Version: 5.7.0-3-MANJARO are you using a Meta key that was assigned *before* KDE was started? or did you use xmodmap to change the modifier setup before trying to use it? i've been doing some reading and have a question. what matters to KDE/Qt? the state bit returned in a keypress event (essentially the alias of a slot in the modifier table) or the keysym associated with the keycode used to trigger the turning on of the state bit? emacs, for example, cares about the *keysym*. the System Settings app (/usr/bin/systemsettings5) cares about the *keysym*. but i'm guessing kwin actually cares about the modifier map slot and has a hard-coded understanding that mod1 is Alt and mod2 is Meta? Seems related to BUG 424266 yes, it has to be the same. i have assigned Alt_L to mod1 again and changed the global shortcut to invoke krunner back to Alt-F2. it does *not* work directly after a reboot but, as in the other bug report, if i restart krunner it, it *does* work. so strange. >as in the other bug report, if i restart krunner it, it *does* work.
Do you mean krunner or kglobalaccel5? In the mentioned bug report kglobalaccel5 was restarted.
kglobalaccel5! sorry, not enough morning coffee :-). Is this still an issue as of plasma 6.1? A lot has changed since the plasma 5 times and maybe the issue has been fixed. 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! 🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. |