[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 --- Comment #12 from kdeb...@chilon.net --- In case anybody else is irritated by this I've written a work-around using kwin scripting: https://github.com/ohjames/kwin-window-switch This script requires my fixes to the following bugs to be patched in:

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 --- Comment #11 from kdeb...@chilon.net --- I accept you're correct with respect to how the tabbox is currently implemented, however I'm sure this an be achieved via alternative means. I'm thinking I can write a kwin-script that will select the next/prev

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 --- Comment #10 from Martin Gräßlin --- > different button it wouldn't be a "significantly breaking experience" that > they get the alt-C shortcut rather than it being ignored. I'm sorry, but this is currently technically impossible (limitations of X,

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 --- Comment #9 from kdeb...@chilon.net --- > In this case, I doubt it can be changed without significantly breaking the > experience for everyone else. If someone is holding alt and pushes tab and continues holding alt, they are likely to only push ta

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 Martin Gräßlin changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 --- Comment #7 from kdeb...@chilon.net --- Angry? I don't think most people will accept facts like this, or will they raise a bug report. They'll just move on. I know one other person personally who finds this behaviour very annoying so probability dicta

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 --- Comment #6 from Martin Gräßlin --- I'm sorry for the inconvenience this behavior causes for your workflow. Unfortunately it's the way it is and has been like that for ages. TabBox is a modal mode controlled by holding a modifier. As long as a modif

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 --- Comment #5 from kdeb...@chilon.net --- Another thing, when you disable the tabbox visualisation, there shouldn't be any need for tab box mode at all. The shortcut could simply select the next window without entering any kind of mode. -- You are rec

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 --- Comment #4 from kdeb...@chilon.net --- I hold alt, hit tab a few times, then hit J... KDE should be able to detect alt-J is not a window cycling shortcut, end tabbox mode, and send alt+J, interpreting it as a shortcut if it is a shortcut. That behavi

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 --- Comment #3 from kdeb...@chilon.net --- Why can't hitting a different key end the mode and apply the appropriate mode? Surely a bug this annoying can be circumvented? Cycling windows and desktops are the two most used KDE shortcuts by far, having to

[kwin] [Bug 370542] Shortcuts blocked as long as tabbox modifier is hold

https://bugs.kde.org/show_bug.cgi?id=370542 Martin Gräßlin changed: What|Removed |Added Component|core|tabbox Summary|I bound windows+H/L