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

2016-10-28 Thread bugzilla_noreply
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

2016-10-13 Thread via KDE Bugzilla
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

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

2016-10-13 Thread Martin Gräßlin via KDE Bugzilla
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

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

2016-10-13 Thread via KDE Bugzilla
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

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

2016-10-13 Thread Martin Gräßlin via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=370542 Martin Gräßlin changed: What|Removed |Added Resolution|--- |WONTFIX

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

2016-10-13 Thread via KDE Bugzilla
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

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

2016-10-12 Thread Martin Gräßlin via KDE Bugzilla
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

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

2016-10-12 Thread via KDE Bugzilla
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

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

2016-10-12 Thread via KDE Bugzilla
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

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

2016-10-12 Thread via KDE Bugzilla
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

2016-10-12 Thread Martin Gräßlin via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=370542 Martin Gräßlin changed: What|Removed |Added Component|core|tabbox