SUMMARY After changing the global shortcut designed to invoke krunner from Alt-Space/Alt-F2 to Meta-F2, I can't invoke krunner by pressing Meta-F2. With the input focus set to the desktop root window, I can still invoke krunner by typing printable characters like "xterm" or "emacs". STEPS TO REPRODUCE 1. Use the System Settings app to modify the global shortcut defaults for invoking krunner from Alt-Space and Alt-F2 to just Meta-F2. 2. Type Meta-F2 OBSERVED RESULT Krunner does not drop down. It is not started automatically if it isn't already running. EXPECTED RESULT The krunner one line input window should drop down from the top of the screen. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 32 Workstation Edition KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION This behavior was persistently observed after using xmodmap to change my physical Alt_L key to emit the Meta_L keysym event. The physical Alt_R key was unchanged and still emits Alt_R.
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.