Bug 161325 - remember window positions throughout temporary unplugged external monitor
Summary: remember window positions throughout temporary unplugged external monitor
Status: RESOLVED DUPLICATE of bug 412703
Alias: None
Product: kwin
Classification: Plasma
Component: xrandr (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 342121 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-27 13:14 UTC by Elmar Stellnberger (AT/K)
Modified: 2021-11-06 12:05 UTC (History)
10 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 Elmar Stellnberger (AT/K) 2008-04-27 13:14:09 UTC
Version:           Unbekannt (using 3.5.9 "release 57.4" , openSUSE )
Compiler:          Target: i586-suse-linux
OS:                Linux (i686) release 2.6.16.54-0.2.3-default

By the deployment of an external monitor notebooks can nowadays be used unrestrictedly as a portable desktop computer. True mobile computing will result in frequently plugging/unplugging an external monitor or certain input devices.
  What a pitty that the original arrangement of all the windows spread across six or more different virtual desktops will be lost as soon as the external monitor is disabled.
  The feature request would be to let KWin remember the positions of all windows that have been located on the monitor being disabled and now need to be moved to the screen of the remaining monitor. At least as soon as these windows have not been moved while the ext. monitor had been unplugged their original state should be restored upon reactivation of the second screen/monitor.
Comment 1 Luke-Jr 2010-09-17 20:46:05 UTC
Confirmed for KDE 4.4
Comment 2 Martín Cigorraga 2013-02-03 22:35:15 UTC
I'm not sure about how easy to implement is this but I agree that this is a much needed feature.
For example, my laptop's screen is 17,1" / 1600x900 while my home monitor screen is 23" / 1920x1080 so the rules I made for windows positioning in my laptop aren't honored when I use the bigger monitor.
Take a look (first row sports 1600x900 screenshots while the second row sports the 1920x1080 screenshots):

http://i.imgur.com/PWgDnXX.jpg  vs.  http://i.imgur.com/RpDuXL1.jpg
http://i.imgur.com/zwC63sE.png  vs.  http://i.imgur.com/Xke7yhO.jpg
http://i.imgur.com/J75wOM6.png  vs.  http://i.imgur.com/e4olwwz.jpg
http://i.imgur.com/ynGZONn.jpg  vs.  http://i.imgur.com/q48mt6k.jpg
http://i.imgur.com/CDn0L2O.png  vs.  http://i.imgur.com/DjtuXBh.png

Seems we need to stop using the absolute (x0,y0) coordinates as a point of reference...
Comment 3 Thomas Lübking 2013-02-03 22:50:17 UTC
Actually the OP demand should have been fulfilled by now (looks like bug #80265, kwin does not care about monitors, but only the workspace dimension what is by xrandr times effectively the same)

Comment #2 is completely unrelated and points resolution dependent rules (or percentual geometry ruling) - please file a new bug on this.

*** This bug has been marked as a duplicate of bug 80265 ***
Comment 4 Robin Green 2014-07-25 08:31:14 UTC
This is not resolved by the fix to bug 80265, please reopen.
Comment 5 Thomas Lübking 2014-07-25 12:00:55 UTC
actually it re-broke with another fix ;-)

diff --git a/kwin/geometry.cpp b/kwin/geometry.cpp
index 6934d26..65944af 100644
--- a/kwin/geometry.cpp
+++ b/kwin/geometry.cpp
@@ -1113,7 +1113,7 @@ void Client::checkWorkspacePosition(QRect oldGeometry, int oldDesktop)
     int oldRightMax = oldScreenArea.x() + oldScreenArea.width();
     int oldBottomMax = oldScreenArea.y() + oldScreenArea.height();
     int oldLeftMax = oldScreenArea.x();
-    const QRect screenArea = workspace()->clientArea(ScreenArea, this);
+    const QRect screenArea = workspace()->clientArea(ScreenArea, geom_restore.center(), desktop());
     int topMax = screenArea.y();
     int rightMax = screenArea.x() + screenArea.width();
     int bottomMax = screenArea.y() + screenArea.height();


But I'll have to test this (or jus dump it into KF5 ;-)
Comment 6 Thomas Lübking 2015-01-07 23:29:43 UTC
Git commit 8de4e4d84ecd0de9046995a07de72323b8754dbe by Thomas Lübking.
Committed on 07/01/2015 at 23:09.
Pushed by luebking into branch 'master'.

determine screenArea by geom_restore in checkWSP

checkWorkspacePosition() operates on geom_restore
to preserve window positions on temporary
(without moving/resizing the window by the user)
screen layout/geometry changes.

Therefore, in the multiscreen case the
screenbound check must be done towards
the screen the window *would* be on
according to geom_restore, not the one
it is right now.
REVIEW: 121320
FIXED-IN: 5.2

M  +1    -1    geometry.cpp

http://commits.kde.org/kwin/8de4e4d84ecd0de9046995a07de72323b8754dbe
Comment 7 Martin Flöser 2015-01-14 08:26:14 UTC
*** Bug 342121 has been marked as a duplicate of this bug. ***
Comment 8 David Edmundson 2015-05-20 23:03:10 UTC
*** Bug 348016 has been marked as a duplicate of this bug. ***
Comment 9 Scott 2020-07-12 21:54:02 UTC
Hey Kwin dev team!  I know this bug is very old and stale, but I wanted to bump it again because it is a significant paper cut for me and it would be great to see it get fixed.  I use a laptop connected to an external monitor, extending the desktop, and every time I unplug the monitor and plug it back in, the windows are all aligned to the right of the screen and I have to reposition them again one by one.  This wouldn't be a significant issue if it were only a few windows, but I tend to have in the range of 60-80 windows open, so it does become annoying and time consuming.

The desired behavior in my mind is:

<unplug monitor>

Kwin moves all windows to main display (or next display over, in the event of 3+ monitors) in the same relative position (ie: if the window is centered on display 2, it will be centered on display 1)

<windows are used/adjusted>

<monitor is plugged back in>

Kwin would move all windows that were originally on the second monitor back to the second monitor, even if the windows have been moved or adjusted.

In my mind, the case could be made for leaving moved/adjusted windows on the first monitor, however I know that when I unplug my monitor and switch to using just the one monitor, I'd really prefer to just have them back on the second monitor.  Essentially for me as a laptop user, plugging in a second monitor is the equivalent of switching my primary display, leaving the second one for things I tend to monitor vs actively working on; I suspect this is a common use case.

An interesting alternative solution in my mind is basically taking that second monitor display and turning it into its own activity (or virtual desktop) that can be switched back and forth from while on only one monitor, which would then return to the second monitor once reconnected.

I'm on KDE 5.18 on Manjaro Linux, if that makes a difference.

Thanks for the great desktop environment!
Comment 10 Grósz Dániel 2020-11-14 02:45:26 UTC
Yes, it still doesn't work well.

With the external screen to the right of the laptop screen (both 1920x1080, external is the primary when it's connected):

Maximized windows get moved to the laptop screen, and stay there when the external monitor is plugged in again.

Vertically maximized windows that were originally on the external screen most often hang off the right edge of the laptop screen when the external monitor is unplugged, and stay there (spanning both screens) when it's plugged in again.

Unmaximized windows have the best chance of being fully moved back to the external screen, but usually not to where they originally were. Instead, they get moved to the right edge of the laptop screen when the external monitor is unplugged, and then moved to the right edge of the external screen when it's plugged in again.

IMO reasonable behaviors would be
(1) either move untouched windows back to where they were, and leave windows that have been moved since the external screen has been unplugged on the laptop screen,
(2) or move all windows to the screen where they were, but retain their locations within the screen (perhaps proportionately if the screens have different resolutions),
or a choice between the two. (1) may be tricky to implement in that automatic resizes of maximized windows (including windows maximized in one direction) shouldn't be counted as changes.
Comment 11 kde.org 2021-11-06 12:05:37 UTC

*** This bug has been marked as a duplicate of bug 412703 ***