SUMMARY STEPS TO REPRODUCE 1. Be on Workspace 1. 2. Have program A not open on Workspace 1 but open on Workspace 2. 3. Open program A, for example by clicking a launcher icon or opening a file. OBSERVED RESULT The desktop switches to Workspace 2. As someone with a similar issue put it, "it's the equivalent of picking up an object and being teleported to a different room". EXPECTED RESULT Program A opens on Workspace 1, i.e. where it was invoked . This would either be a new window (if the application can handle multiple instances) or with the existing window moved from WS2 to WS1 (if it is a single-instance application). Operating System: Arch Linux KDE Plasma Version: 5.22.0 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.9-arch1-1 (64-bit) ADDITIONAL INFORMATION I find it quite disrupting to open a file on one workspace and suddenly end up on a different one. I would assume that it is the expected behavior for the average user to have the program appear on the workspace it is called from, or at least to have the option to configure the behavior such. I do have my task switcher filtered to the current desktop in the window behavior settings. Focus stealing prevention doesn't seem to be the right setting category either. XFCE has this setting: https://unix.stackexchange.com/a/98432/406769 "When window raises itself, bring window to current workspace" This is exactly what I would like to KDE.
Git commit 6b38b0372443b49246b2313673efb0e48a63a978 by Nate Graham, on behalf of Natalie Clarius. Committed on 31/08/2022 at 18:57. Pushed by ngraham into branch 'master'. Add new option for behavior when window on different desktop is activated When a window that is on a different virtual desktop than the current one gets activated, the current behavior is that the active virtual desktop will be switched to the one the activated window is on. This may seem reasonable for a scenario where the user explicitly intends to activate an existing window on a different desktop. However, the following scenario is also (perhaps even more?) common: When an application responds to a launch command by requesting to activate an existing instance instead of opening a new one (such as Firefox or KDE System Settings), an existing window on any desktop will get activated even when what the user had in mind was opening a new window (on the desktop they are currently in). This means that opening an application, such as following a URL or accessing a system setting, unexpectedly results in the user being teleported to a different virtual desktop. This can be very irritating. The more expected behavior for these users would be to have windows always open on the desktop where they are called from. That's is what this commit adds as a new option. FIXED-IN: 5.26 M +17 -2 doc/windowbehaviour/index.docbook M +8 -1 src/activation.cpp M +36 -2 src/kcmkwin/kwinoptions/advanced.ui M +8 -0 src/kcmkwin/kwinoptions/kwinoptions_settings.kcfg M +3 -0 src/kcmkwin/kwinoptions/windows.cpp M +7 -0 src/kwin.kcfg M +11 -0 src/options.cpp M +19 -0 src/options.h https://invent.kde.org/plasma/kwin/commit/6b38b0372443b49246b2313673efb0e48a63a978
Wonderful, thank you very much for this. This has been a big nuisance form e, so I am glad it is fixed already and look forward to seeing it when I get the chance to upgrade!
This quite possibly belongs elsewhere under a different bug, but including here for reference as part of the same user-story, and as KDE is a full suite of applications and not just a single one. This setting has improved the "being teleported into another room" aspect. For me the overall UX when launching an application or opening a new file is still a bit jarring. I have spent many years on Cinnamon where a number of these things have, for what I expect to see happen, "just worked", so now I am having to think about them in terms of what I would expect. The obvious example here is in Dolphin, but it probably applies to other locations - in general, if I am on a workspace where I have an existing application open, then opening in a new tab is preferable. However if I am on a different workspace without an instance of this application, I want to open a new window on that workspace. An easy example of when this behaviour has been most annoying for me is opening text files. If I have a text editor open, such as Kate, I don't want a new window for every single file I open from my file manager - in this instance, a new tab is suitable. It would rapidly become unmanagable having multiple Kate widows open and take focus when I am browsing through Dolphin. And if I don't, I don't want to zoom to another workspace and open it there, nor do I want an existing window of Kate's to zoom to this workspace, I want a new instance to be opened. I usually group my work by workspace, so, for an application like that where multiple windows are supported, if I open a file or application in a workspace I expect it to be presented to me in that workspace. I don't want to be teleported into the bathroom because I am picking up and sorting through some towels, sponges and a rubber dusk; but nor do I want a bathful of water to be teleported into the living room and thrown on me! I want to leave my bath filling up with water in that room whilst I sort out something that is similar on the surface but in terms of my tasks and workflow, semantically an unrelated task, in the living room. Again this is something that historically has just worked for me in Cinnamon/nemo/xed, so I haven't had to think about what logic is being applied explicitly before, the behaviour for me is just what is most expected from the traditional desktop metaphor. If I hit the start menu and select my text editor, I get a new window - the behaviour is different than if I double-click a file in nemo, and this makes sense to me. If I launch an application where a new window in a different workspace isn't possible, then the window gets activated and I an pinged to that workspace or the application comes up in my window list applet in my panel. Opening a song in a media player would be an example where this would make sense (even if this shouldn't focus the window and would probably work in the background) - something like Amarok or Clementine etc., where there is probably a QSingleApplication instance. Or perhaps opening a file in an IDE where there is already an instance open. An application where a new instance would be either overkill or physically can't happen. I presume a certain amount of this is more of a Dolphin setting than for Plasma - but I am not sure. I have used Dolphin on my Mint installation and also used Kate as my text editor, and I don't remember seeing behaviour like I am seeing now on a fully-KDE desktop. Cinnamon (or something along the chain, such as a desktop launcher) somehow seems to make a judgement on whether it should open a new window in the current workspace or raise the file or application in an existing one. Maybe something is different on my system because it's a bit of a surprise if this hasn't seriously annoyed a lot of other people when simply clicking on a text file in Dolphin and trying to open this in Kate. I'd hazard a guess at least a third of users would want the file to open in a new instance of Kate in the current workspace, so if this isn't massively affecting lots of users maybe I am missing something here.
In a more succint summary: ``` if (!existingInstance) newInstance()->open(...) return if (! application can open new (i.e. more than one) instance) if (existingInstance) existingInstance->open(...) return else newInstance()->open(...) return if (existingInstance->workspace == currentWorkspace) existingInstance->open(...) else newInstance()->open(...) ```
Or another way of putting it is that I want any work that I do on a particular workspace preferentially to happen within that workspace over re-using any existing instances. I.e. 80% of the time this default behaviour is what I am looking for in my use of workspaces across Plasma (and any other DE), and the other 20% I am happy to adjust manually.