Ref https://phabricator.kde.org/D3602. TL;DR. I can see the usefulness of this behavior but it's also very annoy when you don't expect it. As the title says, I'd like an option to revert back to the old behavior. Longer version: Here's why I think the old behavior is not "useless" as described in the patch that adds this feature. It is indeed conceptually more consistent with desktop/screen switching behavior but at least one of the big difference is that screen and desktops do not overlap. It is common for windows to overlap and of wildly different sizes to it's already harder to begin with to predict with window is the next one and this behavior makes it even harder. I use these shortcut to navigate between windows quickly and with this change it takes a lot more effort to count the number of times I pressed the key because I can't hold down the key for 1s and expect it to end up in one of the two windows on the left side of the screen anymore. It's true that it should only about double the targets on average on my setup since my windows are usually either left or right tiled but tracing a semi randomly moving focus takes much more effort.
Sorry, but we got usability feedback on that. Making this configurable makes the configuration more difficult to use and increases the maintainer overhead.
What's the usability feedback? I've seen https://phabricator.kde.org/D3602#70700 but it doesn't seem to make sense for me. > Those who would not expect the wrap-around behavior would not expect anything to happen at all, and therefore not even press the shortcut if they are at the left-/rightmost window. This is omitting the fact that keyboard can autorepeats. Also, I've already tried that for more than a week and still couldn't get used to it. Other behavior changes that are indeed possible to get used to usually takes less than a day of continuous using. Why would this increase maintainer overhead? Is there anything very bad about adding such an option? Code wise it should be a one line change (other than adding the option itself) to skip the retry block.
> Why would this increase maintainer overhead? Is there anything very > bad about > adding such an option? Code wise it should be a one line change (other > than > adding the option itself) to skip the retry block. Plasma 5.8 has a regression in a hardly used feature (shading). Plasma 5.9 has a regression in a hardly used feature (virtual maximize, then quick tile). I'm not going to add a config option for another hardly used feature. The hardly used features and the amount of config options we have are the cause for shaky quality. We don't have the resources to properly maintain the amount of config options. Introducing a config options means the possible number of option combinations doubles. We have already more than 50 different options in KWin core, plus all the effects with all their options. We cannot just add new options without properly thinking it through. Given that I requested usabililty feedback on the change in question and made it a requirement that we switch to one or the other behavior. But not both.
In that case, consider this a request to revert the behavior since I don't think the usability feedback considered the effect of keyboard autorepeating.
Also, although I'm not that familiar with how the auto testing is done on X11, it seems that this should be a relatively easy thing to test for both options and should not be strongly coupled to other options so detecting breakage should be possible.
Yet another acceptable solution would be to expose the new `switchWindow` function in the KWin scripting interface (I thought it's possible to trigger script with hotkey/add hotkey from a script?). I'm happy to implement and add test with either methods though I'll need some help for how to add a test for it.
I don't think that autorepeat changes anything. We have quite a few global shortcuts which do not work correctly or do not make sense when keys auto repeat. Common examples are Alt+Tab, Present Windows, Mute, etc. etc. In fact only very few keys make sense with auto repeat, prominent example Lower/Raise Audio. Given that we don't have special handling for any global shortcut with regards to auto repeat I don't think this needs adjustment. It is up to the user to configure a global shortcut which won't auto repeat. I'm setting this again to wontfix and this is the final maintainer decision.
Right, there are a lot of shortcuts that shouldn't be used with autorepeat, but the change turns these ones from autorepeatable to not autorepeatable and therefore one of the most important statements in the usability feedback namely > Those who would not expect the wrap-around behavior would not expect anything > to happen at all, and therefore not even press the shortcut if they are at the > left-/rightmost window. is wrong.
I'm not going to further discuss this in the bug report. If you think the design feedback is wrong, please raise it in the phab request. As I wrote in the phab request I keep out of the usability decision on that. I completely trust our design team there, thus I won't overrule their decision.
I assume by that you mean https://phabricator.kde.org/D3602 ? I didn't want to comment on a merged pull request so I opened a bug report. I'll comment there instead.