SUMMARY STEPS TO REPRODUCE 1. open dolphin 2. open another dolphin window OBSERVED RESULT new windows from the same app get placed in the same position, overlaying the old window EXPECTED RESULT Kwin honors the "Window placement" setting SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION
changing the "Window placement" setting always give the same results aka Kwin ignores the setting
This problem has also started affecting me. Konsoles used to be placed with minimal overlapping but now my konsoles all stack in the exact same spot. Also running kwin 5.19.5 on framework 5.74.0 with QT 5.15.1.
Can you include some screenshots please.
FYI https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/9
reverting bbcfcc53429783b365b3b323d652108980d00b5f fixes the problem seems they commited code that doesn't handle new instances correctly ... // TODO: how should we handle the case when a new instance is opened // and there's stored window position data? Cascade the new window? // Don't restore position and let the window manager handle it? Can // we even know this from here?
another workaround is mentioned in commit 39f7171d5ef3dea7a911b9d9b8088420c39df81a "Allow opting out of remembering window positions on X11" add the following line to the ~/.config/kdeglobals file under [General] AllowKDEAppsToRememberWindowPositions=false
Not honoring the KWin window placement modes is intentional. We got endless bug reports asking for windows to remember their prior positioning, which is mutually exclusive with KWin deciding where to place windows. You can't do both; it's one or the other. Evidently lots of people want KWin to be in control instead, which I did not anticipate given the sheer magnitude of bug reports and duplicates asking for the opposite (23). Sorry about that. For people who do want KWin to always be in control, there is a GUI option visible in Plasma 5.20 to turn off the "remember positions" behavior. Users of Plasma 5.19 who don't have that option visible can add AllowKDEAppsToRememberWindowPositions=false under the general section of their ~/.config/kdeglobals file. Handling multiple instances of the same app opened one after another is a legit bug. Let's use this to track it.
It would be awesome if only the last closed main window of an application would record its window size (to be used next time it opens), while additional instances use the window manager to place the window.
My thinking was to cascade them, but that could work too. However I ran into a problem of figuring out in kxmlgui how many instances were currently open. Would you know how I can do that?
If I open Dolphin two times, I get two results from 'qdbus-qt5 | grep dolphin'. Not exactly sure if this information is exposed outside of D-Bus, or if KDBusAddons knows about this.
Hmm, that's certainly a good starting point! Thanks.
I;m going to try my best to have this fixed for Frameworks 5.75
*** Bug 421735 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/25
It wasn't as hard as I thought, once I tapped the intellectual might of the KDE community. :)
Git commit ab43b986f3de20ff15b6438e56bfe29428bee3b1 by Nate Graham. Committed on 01/10/2020 at 22:43. Pushed by ngraham into branch 'master'. Don't overlap main windows when opening additional instances Right now when restoring the position of main windows, we do it unconditionally. This means that if you have a KXMLGui-using app open and you open a new instance, the new instance gets position- restored and totally overlaps the existing window. This is not very nice. With this commit, that issue is fixed. Technical explanation: To accomplish this, now every time the window position data is read, we write out a value to the config file that indicates that we should not restore the position of the next window to be opened. This ensures that after opening one instance, the next one will never cover it up completely. Whenever any window is closed, we clear the config file value so that the next-opened window can once again restore the position of the last- opened one. This is functionally equivalent to clearing the position config data on disk after reading it, but is simpler and does not result in that data being lost if the app crashes (in which case the main window wouldn't get closed nicely to write the data out again). UX explanation: Apps where you regularly open multiple instances will no longer overlap one another, and the last-closed instance will be the one which gets its position saved. When you re-open that app after closing all instances, it will remember the last position of that window, but opening additional instances will let the window manager position them according to its own window placement settings. FIXED-IN: 5.75 M +15 -30 src/kmainwindow.cpp M +0 -2 src/kmainwindow_p.h https://invent.kde.org/frameworks/kxmlgui/commit/ab43b986f3de20ff15b6438e56bfe29428bee3b1
(In reply to Christoph Feck from comment #8) > It would be awesome if only the last closed main window of an application > would record its window size (to be used next time it opens), while > additional instances use the window manager to place the window. That's what it does now. :)
it works for apps like dolphin now but apps like konsole still get put ontop of each other. The bug is only partly solved, I'm on KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.75.0
reopend the bug
Please define "apps like konsole." Do you mean just konsole, or all terminal emulator apps, or some other set of apps? Can you tell me which apps specifically are still doing this?
konsole is the only app where i can still reproduce the bug
set status to reopened
Ok just Konsole then. So that's an app-specific bug that will end up with a Konsole fix. :) I will investigate. If you feel the need to track that with a further bug report, please open a new one for Konsole specifically. Thanks!
On a quick investigation, this looks fishy: https://invent.kde.org/utilities/konsole/-/blob/master/src/Application.cpp#L263 I would hazard a guess that Konsole was always slightly broken here, but nobody ever noticed before since it only affected the main window's size, not also its position. Now that position data also gets saved, the pre-existing bug become more noticeable. Please do file a bug on Konsole and feel free to mention the above.
Just an observation and comment on how the "window manager" does not keep track of the windows it opens and I assume manages. Why can't the window manager just be responsible for returning the information of what windows are open, what monitors and virtual desktops the windows are on and their position and size? then be able to report this to the session manager. Having to open individual bugs to get all this working and pushing the responsibility to each application seems a bit backward and a flawed design. Can we just not fix the window manager once and for all and be done with it? Is this technically impossible to ask for? I honestly don't see the point of having the session manager feature with this flawed implementation.
If I recall, that was literally the first bug report I filed on a KDE thing, and I remember asking the same question: "uhh, what do you mean the window manager doesn't know where the windows are!? WTF?!!!" :) The short answer is that on X11, windows are allowed to position themselves per the original X11 spec, and the window manager could cause even greater problems by interfering with this when the window isn't expecting it. For example, KRunner, Kickoff, notifications, or Plasma applets might sometimes open in random parts of the screen, rather than in the fixed locations where they currently appear. This works on X11 because these windows are positioning themselves. On Wayland, the window manager is indeed exclusively responsible for window positioning as you expect--correcting this deficiency in the original X11 spec. And in fact, we are working on a version of this feature in KWin itself that works much better. It would basically be a new positioning mode called "remember prior positions". You can follow Bug 15329 to follow the progress of that much better implementation of the feature. However on X11, we need to have this somewhat awkward approach where the window manager only does it if the window does not explicitly ask to position itself
but why file a bug on konsole when disabling this feature fixes the bug?
status
and to be honest, this feature is broken. 1) Open a dolphin window (position A) 2) move it around (position B) 3) close dolphin 4) reopen dolphin, it will now pop up at A instead of B nice idea, but it needs some rework imho ...
(In reply to Jim Jones from comment #27) > but why file a bug on konsole when disabling this feature fixes the bug? Because the bug you describe is caused by Konsole at this point, not by the code in KXMLGui. (In reply to Jim Jones from comment #29) > and to be honest, this feature is broken. > > 1) Open a dolphin window (position A) > 2) move it around (position B) > 3) close dolphin > 4) reopen dolphin, it will now pop up at A instead of B > > nice idea, but it needs some rework imho ... Works for me. Sounds like yet another different bug. --- FWIW the way bug trackers work is that each separate issue needs a separate bug report. See also https://community.kde.org/Get_Involved/Issue_Reporting#One_issue_per_Bugzilla_ticket
(In reply to Nate Graham from comment #30) > (In reply to Jim Jones from comment #27) > > but why file a bug on konsole when disabling this feature fixes the bug? > Because the bug you describe is caused by Konsole at this point, not by the > code in KXMLGui. > > > (In reply to Jim Jones from comment #29) > > and to be honest, this feature is broken. > > > > 1) Open a dolphin window (position A) > > 2) move it around (position B) > > 3) close dolphin > > 4) reopen dolphin, it will now pop up at A instead of B > > > > nice idea, but it needs some rework imho ... > Works for me. Sounds like yet another different bug. > > --- > > FWIW the way bug trackers work is that each separate issue needs a separate > bug report. See also > https://community.kde.org/Get_Involved/ > Issue_Reporting#One_issue_per_Bugzilla_ticket No, correct intuitive way would be: 1) Open a dolphin window (position A) 2) move it around (position B) 3) close dolphin 4) reopen dolphin, opens at B aka store the position at close time of the last running instance
Yeah, that's exactly what it does for me. I'm sorry it's not working for you. Can you please file a new bug report, as that issue is unrelated to the issue being tracked by *this* bug report. Thanks!
i created a new bug report https://bugs.kde.org/show_bug.cgi?id=427621
*** Bug 427610 has been marked as a duplicate of this bug. ***
There seems to have been a regression; I'm getting the same bug with Dolphin on current stable Kwin.
X11 or Wayland? Please try the following: 1. Be on X11 2. Set the window placement mode to "Centered" (or make sure it is already set to this) 3. Open Dolphin 4. Move it to some location that is not in the exact center of the screen 5. While that Dolphin instance is still open, open a new one. If it appears in the same location as the existing instance, that's a regression.
Yes, on X11. When I move the first window, the ones opened after that do not overlap the first window. However, - All subsequent windows overlap the second window. - When the moved window is moved back into its original position, all further windows overlap it. - When all windows are closed, all new windows open in the remembered location (notably, if any window has been moved before it got closed the location of the new windows will be the location of that window, even if it was not the lat one to be active), overlapping. So moving a window saves that window from being overlapped in its new position, but overlap still occurs on windows which are position-restored but unmoved, or moved back.
Clearer wording: It seems that moving a window saves the first moved position from being overlapped (even after the window no longer exists or not in that location), but restored positions will be overlapped.
Ok, that seems like an unhandled case with the fix for this bug, not a regression. Can you open a new bug report for it, and put 426725 in the "see also" field? Also, if you want to take a crack at fixing it, you could see the last commit for this code: https://invent.kde.org/frameworks/kxmlgui/-/commit/ab43b986f3de20ff15b6438e56bfe29428bee3b1
> even after the window no longer exists or not in that location No, sorry, that part was wrong. When the window has since been moved ot a different location, the previous moved location is still blocked, but when the window is closed, that blocked position becomes the one for windows to be restored in, even if other windows have been active in different positions in the meantime.
Okay, I was looking at the steps described in the OP and that matched the behavior I'm seeing; but if that's a different issue I'll open a new one. I'm interested enough to take a look at it, but not familiar yet with how window handling outside of KWin works so not sure about the prospects of success.
Basically on X11, before KWin draws a window, it first checks to see if the window has requested to be opened at specific position on the screen. If it has, KWin honors that request. This feature is using that communication channel. On Wayland, this doesn't happen; KWin always positions it as there is no standardized way for the window to ask for a specific position on screen. That's why this feature only works on X11. On Wayland, we'll have to make KWin itself gain a window position memory feature. But once we do, it will apply to *all* windows, not just a subset of KDE windows, as this feature does.
Okay, I'll give it a try. Here is the new bug report: https://bugs.kde.org/show_bug.cgi?id=452564
I should add that I'm not using the position remember option myself, but was made aware of the issue by someone who has been using that option (with the minimal overlap placement) for a while and only recently experienced this being a problem, and I was able to reproduce it so assumed it was a regression of this bug, but I don't know for sure what Plasma version or other configuration that may influence this they had previously.