| Lint Skipped |
| Unit Tests Skipped |
How are users supposed to know about this? I'm strictly against adding further "magic" to PW or to implement personal features.
I don't think this is adding functionality; we are just mapping a mouse workflow to a keyboard workflow. In my humble opinion, Present Windows is the most useful desktop effect and its only drawback is that it obligates me to use mouse to perform some actions.
That said, my first idea was to connect the equivalent global shortcuts to Present Windows. However, I couldn't find a example of how to do it. Do you think that it would make sense to use the same mappings as the global shortcuts? Do you have any advice on how to achieve this?
That would also be "magic". How would a user know about it? That is my main concern. We cannot just add key handling and not tell users about it. If we accept this review - or the idea of global shortcuts - we would have a workflow suited for you and nobody else. Nobody would be able to use this unless reading the source code.
And that's the difference to the mouse workflow. With mouse we can configure which action it triggers and thus we inform the user about it.
I don't mind in general to add keyboard support, but we need to have the user story right, before accepting it.
The way I see it, it would be very natural to assume that global shortcuts would trigger equivalent functionality while in the effects (not just in Present Windows, but in all of them; I would be please to search and implement the missing ones). Actually, I came across this change after trying "Keep Windows on All Desktops" shortcut instead using mouse clicks.
And that's the difference to the mouse workflow. With mouse we can configure which action it triggers and thus we inform the user about it.
Do you think that we could change the configuration dialog to add the entries for the mappings I'm proposing?
ps: in Present Windows effect, I also think that it would make sense to respond to "Window to Desktop ..." shortcuts (I've also tried those before proposing this change).
Our effects are designed in a modal way. Also the shortcuts are kind of modal. So from usability perspective I'm not sure whether it makes sense. Let's assume I'm in the cube effect. This effect is only about switching virtual desktops, why should I be able to interact with the windows? Similar why should Present Window - which does not give any information about the desktops - interact with desktops?
And that's the difference to the mouse workflow. With mouse we can configure which action it triggers and thus we inform the user about it.
Do you think that we could change the configuration dialog to add the entries for the mappings I'm proposing?
That could be a solution. But I still find it very hidden (only very experienced users would find this) and honestly I'm even a little bit afraid of users trigger the shortcuts by accident. This needs feedback from usability experts. @colomar any ideas?
ps: in Present Windows effect, I also think that it would make sense to respond to "Window to Desktop ..." shortcuts (I've also tried those before proposing this change).
Eh no! Present Windows is not a window manager inside a window manager. It's just for selecting the window.
Okay, to be honest: I don't fully understand what you guys are talking about ;)
It is so hidden. Open Systemsettings -> Desktop Behavior -> Desktop Effects -> Search for present windows -> open the configuration
- Where do these shortcuts come from, where do they already exist?
The shortcuts in this review: nowhere.
KWin *has* global shortcuts for minimizing and stickyness. Those should either be forwarded or picked up from KGlobalAccel, rather than adding some randonmly hardcoded strings where the user might have entirely different expectation on what they do.
Naturally there's none for sending a window to the current VD (because the shortcuts apply to the active window and the active window is on the current VD - or there's a bug in kwin ;-) but I'm not even sure whether that makes any sense in the context of PW, at least no in all configurations and notably not since selecting a window will implicitly pick the current VD (and might alter it), ie. you
I consider this the right path to follow. I hardcoded those because I couldn't find samples showing how I could retrieve the shortcuts from KGlobalAccel. Do you have any idea?
Naturally there's none for sending a window to the current VD (because the shortcuts apply to the active window and the active window is on the current VD - or there's a bug in kwin ;-) but I'm not even sure whether that makes any sense in the context of PW, at least no in all configurations and notably not since selecting a window will implicitly pick the current VD (and might alter it), ie. you
- start on VD#1
- highlight window #A, send it to the "current VD"
- activate window #B on VD#2
- is #A on VD#1 or VD#2 ?
In the current implementation, #A will be at VD#1 and, at the end of the effect, your focus will be VD#2. It might be because I use PW a lot, but this outcome seems very straightforward to me.
Regardless, the "bring window to the current VD" is the only reason I came across proposing this change. The others shortcuts I implemented just for completeness. Indeed, I find it very strange that I can minimize windows through PW.
The desktop grid seeems more suited to handle the windows VD.
There're PW modes where this feature is pointless (because you only see the current VD anyway) and for the other ones there's (as mentioned) no feedback nor oversight on the status quo. Nor is there even visibility of the feature.
A merge between PW and DG (aka "Mission Control"; what you seem to be after?) would imo require a sane re-draft of such effect/tool.
I find it very handy to manage windows using Desktop Grid when I am at home where I interact with kwin/plasma mostly using mouse. I can drag and drop windows around and all stuff.
However, while at work, I make full use of keyboard and shortcuts. Currently, if I want to bring any window to the current desktop, I must go to that desktop (meta+1|2|34), send the window to the desktop I wish (meta+alt+1|2|3|4), and move back to the first desktop (meta+1|2|3|4).
Using PW, I can trigger PW, move to the window typing its name or moving using arrow, trigger "bring to current VD", and end the effect.
There're PW modes where this feature is pointless (because you only see the current VD anyway) and for the other ones there's (as mentioned) no feedback nor oversight on the status quo. Nor is there even visibility of the feature.
A merge between PW and DG (aka "Mission Control"; what you seem to be after?) would imo require a sane re-draft of such effect/tool.
No, I think PW and DG should be different tools each one suited to a use case: DG for mouse workflows, PW for keyboard workflows (or mixed keyboard/mouse workflows). DG, in my humble opinion, is feature complete when considering mouse workflows and we shouldn't change it.
I really think we could improve PW to encompass VD information (below the window name?) and enable the use of global shortcuts to trigger actions such as moving a window to another VD (or even screens).