SUMMARY On Wayland with two monitors set up the windows seem to appear always on the wrong screen for me. Is there something I have to set up to make it work as expected or is this functionality still missing?
BTW: This also happened to the overlay for shutting down the computer. Might be a different bug, though.
Can you define "on the wrong screen"? What is it that you expect, and what happens instead?
Created attachment 131202 [details] Dual screen setup See my monitor setup attached. The applications always start on the left vertical screen, while I want them to start on the right horizontal screen with the panel. (Or remember their position, but that would be a different bug probably ;)). I start the applications either through the application launcher (Kicker) or by clicking the icon in the icon only task manager on the panel. This also happened with Firefox now on X11 for me, but might have a different cause.
After using the setup for some time now, I can report that sometimes apps (Firefox) open on one screen and sometimes on the other. Most times on the "wrong" screen, though.
Just had some more testing. I used default settings before. After selecting "active screen follows mouse" it works on Wayland (and on X11). Apparently one has to click the screen to make it the active one else? I expected to have the primary one to be the active one after login, if the "active screen follows mouse" option is not selected. So I still consider the current default setting to be not working as expected. Since this is probably not Wayland related, I am removing the keyword and adjust the title.
The current default starts at 0,0 which will be the upper left and fills out. There is no attempt to take primary screen into account, so AFAIK all code is working as-intended. Though that still leaves the open question of whether the code intention matches user expectation.
(In reply to David Edmundson from comment #6) > The current default starts at 0,0 which will be the upper left and fills out. Ah, makes sense, then. > There is no attempt to take primary screen into account, so AFAIK all code > is working as-intended. > > Though that still leaves the open question of whether the code intention > matches user expectation. It was not my expectation at least. I set up my monitors and saw the "primary" option. I thought that would have some effect. Some options that came to my mind: - Change the code to maybe consider the primary monitor setting for that - If a change is not wanted (this might not be the intended behavior) introduce an additional option and make it default - Make the option "active window follows mouse" the default To me the second option seems to make the most sense, even if a change would be ok. This offers an additional option, so the user has more room to choose from if he prefers the current default behavior.
I thought Wayland didn't have a concept of "primary screen"? So is this X11-specific?
(In reply to Nate Graham from comment #8) > I thought Wayland didn't have a concept of "primary screen"? So is this > X11-specific? Happening on both X11 and Wayland, due to the reason David mentioned, I guess. In the comment above, I forgot that there is no "primary screen" in Wayland. Sorry introducing confusion and unnecessary noise by that. Most options I gave are thus probably no longer applicable. My knowledge about what options are possible or sensible is limited. However, to me the only option to mitigate the problem seems to make "active window follows mouse" the default? Is this ok to do (and will this introduce unwanted side effects)?
A short ping, since the discussion seems to be stalled, currently.
Changing "active screen follows mouse" to true by default seems to be a good first step to mitigate the problems. Corresponding line seems to be https://invent.kde.org/plasma/kwin/-/blob/master/kwin.kcfg#L105. Since other problems that got fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/130 it seems to be a bit harder to change the default, though.
You would need to flip the default value of SeparateScreenFocus and ActiveMouseScreen in kwin.kcfg and kcmkwin/kwinoptions/kwinoptions_settings.kcfg. Hope that helps. As for regressions, I've been using kwin with those options turned on for about a year or two and haven't found any serious issues.
Perhaps we should change the defaults in this case? Would that make sense?
Thanks for the hints. I could look into this soon, although don't really have time to also test the change probably. So if somebody else wants to do it...
Either CCBUG did not work or the bot is currenlty not active. I started a MR: https://invent.kde.org/plasma/kwin/-/merge_requests/468.
Git commit bcba2e252f58edbeb0c6b790df1a4148656ec981 by Vlad Zahorodnii, on behalf of Claudius Ellsel. Committed on 27/11/2020 at 08:18. Pushed by vladz into branch 'master'. Change the defaults for active screen As suggested in https://bugs.kde.org/show_bug.cgi?id=425798#c12. M +1 -1 kcmkwin/kwinoptions/kwinoptions_settings.kcfg M +1 -1 kwin.kcfg https://invent.kde.org/plasma/kwin/commit/bcba2e252f58edbeb0c6b790df1a4148656ec981
Should this be marked as resolved now that the defaults have been changed (since that's what the bug report is about?)
Currently that MR caused problems with tests that I don't really know how to fix and will thus probably reverted for now. Also I am not sure whether this MR fixes the underlying problem of this bug. Possibly that is the case, since there is probably no better way to set the active screen where windows are opened for now and there are already other bugs for remembering window positions on Wayland.
Looks like it was reverted. :( I see that the code is supposed to enable "active screen follows mouse" mode when you're not using the "click to focus" setting. Are you using it? If not, that would be seem to be a bug.
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!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone!