https://bugs.kde.org/show_bug.cgi?id=491644
--- Comment #7 from Oded Arbel <o...@geek.co.il> --- (In reply to fanzhuyifan from comment #5) > (In reply to Oded Arbel from comment #4) > > So one has to wonder - if I have META assigned as the modifier-only shortcut > > to trigger the application launcher - why pressing SHIFT+ALT and releasing > > it not opening the application launcher? > > Works for me on git, wayland, if alt is released with shift pressed. That is interesting - I cannot reproduce this on Neon testing (currently claiming 6.1.5). Using <Press SHIFT, P ALT, R ALT, R SHIFT> does not trigger the application launcher that is configured for META. Trying to use that sequence in the shortcut setting shows up as META+ALT+SHIFT (as mentioned on top) and then I can't actually trigger that with the same sequence (though using real META+ALT+SHIFT works). > IMO native key codes are more reasonable than the physical scan codes. E.g., > I use a hwdb config to map my CAPS_LOCK to ESC, and I would want shortcuts > containing ESC to trigger when I press that key. If I understand correctly, > using scan codes means it will still be interpreted as CAPS_LOCK. I'm not familiar with that concept. KWin debug console shows scan codes, Kxb symbols (keysyms) and Qt::Key codes - which I believe are Qt internal representation of keysyms. > One potential issue with not using keysyms is we cannot get consistent > behavior for default shortcuts like Ctrl++ under different layouts. I believe it was demonstrated, by you in bug #434988 and elsewhere (my pet peeve is bug #453661), that both approaches have their drawbacks and the current behavior causes quite a lot of grief (my Yakuake pull down terminal is not accessible when I'm on the Hebrew layout, which is ridiculous). > we might want users to use the physical key > corresponding to the + symbol in their own layout. This is also what Qt > does, and I am wary of deviating from that. > (https://doc.qt.io/qt-6/qkeysequence.html#keyboard-layout-issues) Qt has a lot of heuristics to try to extract meaning of the mess that is layout-specific keysyms, as detailed in bug #453661 and linked Qt bugs, and those heuristics cause a lot of damage in and of by themselves. Anyway - to keep moving forward, what I would suggest is that for modifier-only shortcuts - that are only resolved on release anyway, to take into consideration only the physical (or native key codes - I'm not sure how you'd go about getting those) and not keysyms. This would also allow you to take advantage of right vs. left side modifiers, as other operation systems do (in Windows RTL, CTRL_R+SHIFT_R are used to force paragraph direction to RTL). -- You are receiving this mail because: You are watching all bug changes.
