| Summary: | Activating an app on a different virtual desktop always switches to that VD or does nothing | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Riccardo Robecchi <sephiroth_pk> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | cwo.kde, czzcy3832515, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.2 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | screen recording showing | ||
|
Description
Riccardo Robecchi
2025-03-10 22:51:32 UTC
Is this weird behavior seen on both X11 and Wayland, or only one session type? I haven't tested Wayland and, given the issues I face due to bug 501346, I am only going to test it the next time I reboot - possibly weeks down the line. Created attachment 179344 [details]
screen recording showing
If I set it to "do nothing" on wayland and click the task manager entry for a window on another VD, the window (which was not minimized before) plays the unminimize animation on the current workspace, is shown for a fraction of a second, then plays the minimize animation. (It's still not minimized on the workspace it's actually at).
This does feel rather broken. I've attached a screen recording showing the issue; it's actually too fast for Spectacle to consistently capture so some of the clicks don't show up.
I'm not sure about what the correct behavior in general (apart from this visual issue) is. On the one hand, having the icon there when it doesn't do much feels weird, on the other hand this is a natural consequence of these options. I can see the appeal in the use cases provided in the bug report, but this feels a bit like reimplementing a ccustom version offocus stealing prevention with virtual desktops, and I'm not sure this is the best design.
Changing this to "confirm" given it has been reproduced on Wayland, too. (In reply to cwo from comment #3) > I'm not sure about what the correct behavior in general (apart from this > visual issue) is. On the one hand, having the icon there when it doesn't do > much feels weird, on the other hand this is a natural consequence of these > options. I can see the appeal in the use cases provided in the bug report, > but this feels a bit like reimplementing a ccustom version offocus stealing > prevention with virtual desktops, and I'm not sure this is the best design. I do not see a case in which what we have now is a desirable outcome. I feel that whatever the chosen approach is, there cannot be a situation in which clicking on the icon in the task manager does not raise the corresponding window, because that is simply a broken design. If an exception must be made in the code in order to make it work, then it should. It might be a bit of a corner case, but think of a shared computer in which the "do nothing" option is enabled by one user; another user (as in "person", not "user account") could try to use the computer and find that they can't activate a window due to this. Their experience will just feel broken. (In reply to Riccardo Robecchi from comment #4) > I do not see a case in which what we have now is a desirable outcome. I feel > that whatever the chosen approach is, there cannot be a situation in which > clicking on the icon in the task manager does not raise the corresponding > window, because that is simply a broken design. If an exception must be made > in the code in order to make it work, then it should. I'm skeptical because the user specifically set this up - the task manager by default only shows the current desktop, and the default window activation on a different VD is "move to VD" I think. That it appears broken is because the user selected custom options that have a somewhat unfortunate interaction. Sometimes it might make sense to work around this if we can infer what the user is trying to do, or to show a warning. But in this case I see, for example, no principled reason to prefer moving to the VD that the window is on over moving the window to the current VD – and the user has specifically stated that they do not want either to happen. (And it's not like no one could ever want this particular behavior). There's a cost to making settings do unspecified other things even if these are a clear improvement in some cases. For example, the "Mouse wheel cycles through tasks" option has different behaviors depneding on the task that it is, and the feature is more confusing and harder to extend because of it - there are valid feature requests that are stalled on it being essentially impossible to figure out a good wording that actually explains what it does. *** Bug 468381 has been marked as a duplicate of this bug. *** |