Bug 455197 - Wayland: unlike on X11, launching an app bound to another virtual desktop will switch to that desktop
Summary: Wayland: unlike on X11, launching an app bound to another virtual desktop wil...
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.24.5
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-13 03:11 UTC by tusooa
Modified: 2023-01-12 06:03 UTC (History)
3 users (show)

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 tusooa 2022-06-13 03:11:26 UTC
SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols.
See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***
Create a window rule for an app to start on another virtual desktop. Launch that app, and you got switched to that desktop.

STEPS TO REPRODUCE
1. System Settings -> Window Management -> Window Rules
  Add rule:
  - window class: substring match -> konsole
  - virtual desktops: apply initially -> 5: Desktop 5
2. Launch konsole when I am on Desktop 1

OBSERVED RESULT
It switched to Desktop 5.

EXPECTED RESULT
It should not switch to Desktop 5. It should stay on Desktop 1 and the taskbar should have a highlighted Konsole entry. (Same as on X11)
(Or at least give users a choice whether to switch to that desktop)

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 5.18.3-gentoo-x86_64 / 5.24.5
(available in About System)
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4

ADDITIONAL INFORMATION
On Fvwm the behaviour to not switch desktop on such app launching is called `SkipMapping`. It's a pretty useful feature.
Comment 1 Nate Graham 2022-06-14 16:49:56 UTC
So you want it to launch an app in another desktop but *not* take you there? So then you have to manually switch desktops to see it?

Why?
Comment 2 tusooa 2022-06-14 16:53:19 UTC
(In reply to Nate Graham from comment #1)
> So you want it to launch an app in another desktop but *not* take you there?
> So then you have to manually switch desktops to see it?
> 
> Why?

Yes.

If I launch some app that I know will take some time to appear, I would like to continue with my current work, without being interrupted by the newly-opened window.

Plus, this is and has always been the behaviour on X11. I am so used to it. It is also implemented in other window managers like fvwm.
Comment 3 tusooa 2022-06-14 16:56:04 UTC
Moreover, this feature will be very useful if you *autostart* some apps and just want them to start on other desktops, while keeping the initial desktop clean.
Comment 4 Nate Graham 2022-06-15 18:34:28 UTC
Thanks. The fact that it's different between X11 and Wayland doesn't sound right, regardless of what the currently intended behavior is (I don't know what it is). It's also possible we could make this configurable. I'm CCing someone who is currently working on that for something different but related.
Comment 5 Natalie Clarius 2022-06-15 22:23:50 UTC
The related thing mentioned in the previous comment is https://invent.kde.org/plasma/kwin/-/merge_requests/2201, bug report https://bugs.kde.org/show_bug.cgi?id=438375

XFCE has this with "Do nothing" as a third option: https://unix.stackexchange.com/questions/97918/stop-browser-window-from-switching-workspace-and-getting-focus-when-opening-a-li/98432#98432  I suppose one could do that here too. 

The setting I just talked about here is about window *activation*. I don't know if *addition* of a window in the scenario described in the OP also triggers activation or which parts of it exactly, and what is responsible for the different behavior between X11 and Wayland. I can try to look into it.  

For those who would prefer the desktop not to switch, if such a "Do nothing" setting were to take effect not only on newly launched windows, but also cases where an already existing window on a different desktop gets activated, would this be a problem ?
Comment 6 Natalie Clarius 2022-06-16 05:38:50 UTC
If I am not mistaken, what makes the difference is that Workspace::addWaylandWindow calls Workspace::activateWindow which in turn does the desktop switching (which is target by the related MR), whereas Workspace::addX11Window does not.  

Why it is done that way, what the "right" behavior in this scenario would be and how to change this without breaking something else, someone more experienced than me needs to say.