SUMMARY In Plasma 6, the behaviour when activating an application on a different virtual desktop (VD for brevity) falls under three cases: - the app is activated and the VD switches to the one where the app is; - the app is brought to the current VD; - nothing happens. This is true regardless of whether an app activates another (as an example, clicking on a link in Matrix opens a new tab in Firefox) or whether you click on the app's icon in the task manager. However, this is not how it was until Plasma 5. The way it worked was that the setting for application activation was only relevant in the context of an app-based activation; even when set to "nothing happens", clicking on an app's icon in the task manager would activate it and switch the view to the corresponding VD. This was an intuitive implementation of "do nothing" and allowed for cases where you have, as an example, a messaging application on VD1 and a browser on VD2, and having multiple links to click in the messaging application does not force you to do back and forth between VDs, but you can still switch to the browser easily by clicking on its icon in the task manager. The new Plasma 6 behaviour, on the other hand, just looks broken. STEPS TO REPRODUCE 1. Set the virtual desktop behaviour to "do nothing" 2. Click on an application's icon in the task manager OBSERVED RESULT Nothing happens. EXPECTED RESULT The view switches to the application's virtual desktop and the window is brought to the fore. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION
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.