Via the "Navigation through windows" set your forward/reverse selection through all windows to any key combinations involving the windows keys. Also disable the visualisation effects such as breeze. Now set another key binding that involves the windows key. Now hold down the windows key and push one of the buttons to switch to a window to the right, then while still holding the windows button, push the shortcut you configured second. You will see that the shortcut is ignored, after hitting windows key and pushing any "next/previous" window binding, the windows key is now tainted for good and is impossible to use for any non window navigating actions. I constantly want to do things like: "Switch to next application on desktop, then switch to the next desktop". This bug forces me to keep releasing the windows key again and again. It is VERY annoying. Reproducible: Always Steps to Reproduce: 1. Bind win+j to select the next window via the task switcher system and remove the visualisation animation. 2. Bind win+k to select the next desktop. 3. Open two applications on your current desktop. 4. Hold win and hit j to move to the next application on your desktop. 5. While still holding win, hit k to move to the next desktop. Actual Results: win+k does absolutely nothing, I have to release win and then press it again for win+k to work. Expected Results: I should be able to switch to the next task and switch windows without having to release win in between. I understand why holding win would have a special status when an animation effect is enabled as holding the modifier keeps the animation active (although even in this state, I believe a subsequent key binding should disable the window switching state). When there is no animation there is no reason for this annoying limitation.
This behaviour is so infuriating to me on a day to day basis that I had to give up KDE. First I tried to fix it via kwin-scripting, but key bindings weren't working at all in kwin scripts at the time. Then I went through kwin's source code trying to work out how to fix it myself. There was no option left after this but to abandon KDE because having to constantly keep pressing and releasing the windows key or face key bindings being ignored is just too annoying.
The problem here is that Alt+Tab is a mode which is active till you release the modifier. As long as you are in that mode all other shortcuts are ignored. For the behavior you want you cannot use a shortcut with a modifier, I'm sorry.
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 keep releasing the modifier between them drives me crazy! I don't want to use AwesomeWM, I want to use KDE, but this bug is so irritating it makes KDE unusable for me.
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 behaviour seems far more desirable to me than the current status.
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.
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 modifier is hold the TabBox does not close. The option for showing the TabBox is a visualization hint and has no influence on the behavior. I ask you to kindly accept this fact as it is. Being angry about it won't help you and won't motivate me to work on it. The issue you raised here is a fundamental change on how the TabBox works. This requires investigation. The result of this investigation can be that it's too much work to change for one user.
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 dictates there are many more. The way you explain the information makes sense according to your contextual bias but if you try to pretend you're a brand new user to KDE, or look at this behaviour outside of your context, you'll see the reasoning behind it falls apart and just leads to thousands of extra key presses per day.
Just for context: I have been involved in KWin development for 8 years now. We get about 600 new bug reports every year. I have about 60,000 bug reports email in my inbox. Your the first one for whom this is a problem. If that is a problem which makes KWin unusable for you: you can always move on. Nobody forces you to use our software. That's totally fine. Heck it's even free software which allows you to change the code the way you want. For us as maintainers it's important to see the perspective: how many users require this feature, how important is it and how dangerous is changing it. We know that we cannot adjust the software in ways that it works for everybody out there. That's just impossible. In this case, I doubt it can be changed without significantly breaking the experience for everyone else.
> 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 tab again, shift-tab again or stop holding alt. If they do continue holding alt and then push a different button it wouldn't be a "significantly breaking experience" that they get the alt-C shortcut rather than it being ignored.
> 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, etc. etc.). To make this work one would need to change the implementation in ways which would risk to break the functionality over all. Please trust my experience here if I tell you that this just cannot be done without breaking existing functionality.
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/previous windows outside of the tab box. Or at least I could if kwin-scripts could use shortcuts. I don't want to be forced to use a different window manager just because the keybindings I most frequently used have aberrant behaviour. Sorry if you thought I was angry about this btw, I'm not angry at all! I try not to sound angry but I have a pretty blunt style from aspergers etc.
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: * https://bugs.kde.org/show_bug.cgi?id=340225 * https://bugs.kde.org/show_bug.cgi?id=340125