Bug 389818 - Warn that global shortcut does not include modifier
Summary: Warn that global shortcut does not include modifier
Status: REPORTED
Alias: None
Product: kwin
Classification: Plasma
Component: tabbox (show other bugs)
Version: 5.11.5
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-03 09:02 UTC by tguen
Modified: 2018-02-20 01:19 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tguen 2018-02-03 09:02:16 UTC
In System Settings > Window Management > Task Switcher, there is an option for sort order. If this is set to 'stacking order' and the reverse switch shortcut includes a modifier key (e.g. shift-F1) then it works as expected. If the shortcut does not include a modifier (e.g. F1) then the 'stacking order' option is ignored, and it uses 'recently used' behavior. This bug occurs only for the reverse-switch shortcut, not for forward-switch.
Comment 1 Martin Flöser 2018-02-03 10:04:15 UTC
If the shortcut does not include a modifier none of the options can be used.
Comment 2 tguen 2018-02-03 10:40:29 UTC
If the options don't work properly for certain keys, it should not allow those keys to be set as a shortcut, or at least warn the user that the selected options will not work. Pretending that nothing is wrong, then failing to work as one would expect is not really acceptable design.

As I said, the option *does* works as expected for forward-switch, just not reverse-switch.
Comment 3 Martin Flöser 2018-02-03 13:53:19 UTC
Please in general do not reopen bugs. It won't make it likely to be addressed.

I'm changing to wish as from KWin perspective this means a new feature to warn about the fact that no modifier key is selected. I don't think that this makes any sense as there is also a global shortcuts configuration module, where we cannot warn about this.

Please be aware that it is very seldom that a wishlist item gets actually implemented.
Comment 4 tguen 2018-02-04 00:09:51 UTC
The reason I love KDE is because of the degree of customization it provides. I like being able to set any feature to any keyboard shortcut. I can't imagine why a feature would work with one shortcut but not with another. On top of that, I can't imagine why it wouldn't tell me if I picked a shortcut that won't work, even if it has to be an awkward message box. Anything would be better than nothing.

I'm sure you don't appreciate me reopening the report. I'm sure you can imagine I don't appreciate that after finding unexpected and seemingly buggy behavior, going thru the trouble of checking for an existing report, and typing up a description of the problem, my report was marked as "invalid" with absolutely no attempt made to explain why you think it is.

I don't mean to sound entitled. I'm not expecting a blog post. A one-sentence explanation would be fine. Maybe something like "Unfortunately, due to the way the system is designed, it would take an unreasonable amount of effort to fix the issue." Instead I got a denial that this is even a bug.

I hope you put some thought into how you respond to bug reports, because frankly this doesn't cut it. This kind of attitude is exactly what drives potential contributors away from the community.
Comment 5 Martin Flöser 2018-02-04 17:24:32 UTC
Sorry for the rather short answer and setting to invalid. This was a case of organizational blindness combined with bug report management from a tablet. When reading through the bug I had the code visually in my head and knew that it just doesn't make any sense to not have a modifier and that there is special code which short passes most of the involved options. Due to that I came to the conclusion that in the context of the code we have, this is an invalid bug report. The omit of an explanation like this one here is due to the fact that I used a tablet with rather limited keyboard functionality.

Now I'm also going to explain why I don't like bugs being reopened: the problem is that we get many bug reports and I try to keep the bug tracker clean. This means that bugs which are in the context of KWin invalid are marked as invalid, feature requests which won't be implemented are marked as wontfix. Many times users disagree and just reopen. Then I set them back to invalid or wontfix. And things start to escalate. We had users reopening with comments like: "reopen because I can". That doesn't help and results in fights of users against developers.

Instead I prefer if users add a comment like "I disagree, for this and that reason". Like you did in comment #2. You gave an explanation on why this is problematic which I didn't notice in my first evaluation. I re-evaluate based on the new facts and can adjust the bug if needed.

The bug workflow is then more clear and we don't have the chance to go into the user vs. developer issues.
Comment 6 tguen 2018-02-19 05:55:05 UTC
Well... upon further investigation, it seems I was wrong about what's happening after all. 

With the default shortcut, when I hold alt and press tab it activates 'window switching mode' as long as I hold alt. (I forgot about this, and now understand why a modifier key is required.) While in this mode, pressing tab will switch windows.

The real problem is that while I can change the shortcut to activate the window switching mode, the shortcut to switch windows while in this mode is not changed to match. It is hard-coded to alt+tab/alt+shift+tab.

If I activate this mode with, for example, ctrl+enter, I will remain in this mode until I let go of all modifier keys. If I want to actually switch windows, I have to hold alt, let go of ctrl, then press tab.

I'd imagine this would be considered a bug rather than wishlist?

Sorry for the attitude earlier, I don't want you to have to waste time fighting anyone over the status of a bug report when you could be fixing bugs instead (or, you know, doing anything else).
Comment 7 Martin Flöser 2018-02-19 16:31:46 UTC
If you want to use ctrl+enter as the shortcut you need to use enter instead of tab to switch through the windows.
Comment 8 tguen 2018-02-20 01:19:30 UTC
What I was trying to say is that it wasn't working that way for me. But upon further investigation, it seems I was wrong about what's happening after all... again.

Any key combination will start 'window switching mode' as expected, but the key combination that switches between windows while in this mode doesn't change until I restart kwin.