| Summary: | Virtual window behaviour has changed and excludes the original behaviour | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Peter Humphrey <peter> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | asturm, kde, luigi.toscano, natalie_clarius, nate, nicolas.fella, peter, plasma-bugs |
| Priority: | NOR | ||
| Version: | 5.26.5 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/commit/8c9c45b8f101f1d90b3084530f9e463a2b5915ab | Version Fixed In: | 6.0 |
| Sentry Crash Report: | |||
|
Description
Peter Humphrey
2023-01-14 15:44:42 UTC
You are citing a bug marked as duplicate of bug 462996, which contains a link to a fix here: https://invent.kde.org/plasma/kwin/-/merge_requests/3380 Can you confirm that, after upgrading to KDE Frameworks 5.102 and applying that patch to kwin-5.26.5, your problem is fixed? If I've done the patching without error, the patch makes no difference. The browser is still yanked from where it was to lie on top of everything on the current desktop. I tried two ways of patching: the first time I followed the Gentoo stepwise ebuild process, issuing successive ebuild commands, with the patch after src-prepare; the second I simply dropped the patch file into /etc/portage/patches/kde-plasma/kwin-5.26.5/ and running the standard emerge command; that should have picked up the patch and applied it. That isn't all. I run with Firefox on desktop 3, and I log in and out via sddm. Since upgrading to kde-frameworks-5.102 today, when I log out and then in again Firefox appears on desktop 1 regardless. Is there some confusion between (i) the two new options in system settings and (ii) restoration of the original behaviour? I've been asked to test a patch relating to the former, whilst I am concerned with the latter, as I said in my bug report. What's your "focus stealing prevention" setting? Ah! It was Low, which I don't remember setting. But setting it to Medium has done the trick. Thank you Nicolas. Another one bites the dust... >Another one bites the dust...
So can this be considered closed?
There's something about this that I don't understand. Based on reading the code the behavior is "if focus stealing protection is set to anything higher than 'None' then don't activate apps on other desktops". This part of the behavior didn't change recently. And yet we have multiple people saying it did. What adds to the confusion is that we seem to have different behavior depending on *how* the app activates itself. If the app activates itself by changing _NET_ACTIVE_WINDOW then (before https://invent.kde.org/plasma/kwin/-/commit/6b38b0372443b49246b2313673efb0e48a63a978) and focus stealing protection is none then we would switch to the app's desktop If the app activates itself by changing _NET_STARTUP_ID then we would move the window to the current desktop (or the desktop explicitly specified in the startup id). If focus stealing protection is none then the window is activated. (https://invent.kde.org/plasma/kwin/-/merge_requests/3380 changed this behavior to not move to the current desktop unless the relevant option is chosen). With https://invent.kde.org/plasma/kwin/-/merge_requests/3380 we now have (mostly) consistent behavior between the two cases. But neither https://invent.kde.org/plasma/kwin/-/merge_requests/3380 nor https://invent.kde.org/plasma/kwin/-/commit/6b38b0372443b49246b2313673efb0e48a63a978 changed the behavior of what happens when activating windows on another desktop with focus stealing protection other than None > If the app activates itself by changing _NET_STARTUP_ID then we would move the window to the current desktop (or the desktop explicitly specified in the startup id). If focus stealing protection is none then the window is activated.
Correction: at this point the window is already moved to the current desktop, so it is activated according to usual FSP rules
I've lost track of which bug report refers to which behaviour. In my case, setting focus stealing prevention to not NONE cures the problem of my browser window being dragged onto the current desktop. However, I'm not clear on whether the selection of move-to-desktop or move-browser-here works as it should. Moreover, Firefox is loaded onto desktop 1 when I log in, regardless of where I left it. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! What am I being asked for? Git commit 8c9c45b8f101f1d90b3084530f9e463a2b5915ab by Nicolas Fella. Committed on 14/04/2023 at 19:06. Pushed by nicolasfella into branch 'master'. Add option to do nothing when activating window on another desktop Some users prefer this over the existing options. It e.g. allows to open a bunch of links and only then switch to the browser on a different desktop M +12 -0 doc/windowbehaviour/index.docbook M +2 -0 src/activation.cpp M +5 -0 src/kcms/options/advanced.ui M +1 -0 src/kwin.kcfg M +2 -1 src/options.h https://invent.kde.org/plasma/kwin/commit/8c9c45b8f101f1d90b3084530f9e463a2b5915ab |