This is kwin behaviour; reassigning.  I don't know if it can be improved though...

Someone on Gentoo forums suggested making ksmserver to save some kind of temporary session, then restore if after switching resolution back. Now it seems that is not possible at the moment (at least I couldn't find a way to do it), but maybe this is something to think about. Would be nice enhancement :)

*** Bug 81147 has been marked as a duplicate of this bug. ***

This bug still exists with KDE 3.5.2 on Gentoo. This is particularly annoying if I'm using a program that uses randr to switch to fullscreen with a different resolution (wine and OGRE with the GLX platform manager are two such cases). In both cases the desktop gets messed up.

I do not know enough about the design of the randr extension, but since Gnome handles it correctly, there must be a way to fix this particular case.

On my desktop (kde-redhat binary packages for KDE 3.5.6), there appears to be a little effort to restore window location settings after an XRandR change (at least, windows which are flush with one side of the desktop before a change are flush with the same side of the desktop after changes), however the annoyances are frequent.  Changing from 2560x1024 (dual screen) to 640x480 and back, for example:

Small windows which are flush against the right side of the left screen end up against the right side of the right screen.

Windows which are larger than 640x480 end up maximized to 1280x1024.

Other small windows end up maximized horizontally or vertically, in no pattern I can discern.

Since such resolution changes are used by wine when playing old games, for example, I agree with gregormueckl that it's quite annoying.  Not having windows moved and resized at all would be preferable to having them moved and resized semi-randomly like this, in fact - could we get an option to do that, as a workaround until this three-year-old bug gets a more functional resolution?

I'm all for this getting fixed by someone, though the potential overhead frightens me somewhat. Please save to a file and not to main memory. I don't care if it takes a longer time to switch between resolutions.

There's also the case of adjusting things between resolutions that didn't exist in the saved session. I don't know, I think a solution for that might be like remapping things relative to a weight based on directional orientation. You know, that NW, N, NE, W, C, E, SW, S, SE thing...

I'm having the same issue on 3.5.7 using full screen mode in dosbox.  I guess this is a feature of kwin in that it is trying to adjust to new modes, but perhaps 1) it should only do this when a kde app initiates the resolution change (e.g. the resolution applet or changing the resolution on startup), and/or 2) it should be a toggle.  I would actually prefer that my desktop always be the size of the virtual desktop and that changing the resolution only acts as a "zoom" feature.  (i.e. I would turn the toggle suggested by 2) off.)

I just tried running an old Wine game on KDE4... Unfortunately this problem is still present in Kwin from KDE 4.1.3 :( Pretty annnoying.

Btw: Why is this a wishlist item? Ok, it doesn't crash or loos data, but it's also not the way it's expected to work i.e. a bug (of whatever severity)...

*** This bug has been confirmed by popular vote. ***

Still present in KDE 4.5.3 and still very annoying.

I noticed a similar behaviour when Plasma crashes (yes it does!:). This might be related. In this case the panels are removed and thus workspace area changes. When Plasma was back again I had lots of windows with really tiny sizes...

Sorry for the late reply to this bug report which is actually not a bug, but a request for a new feature to keep track of the sizes of all windows when the resolution changes and restore to it.

I'm sorry to say but this is unlikely to be added. To me there is no indication that such a feature is in fact required, that our user base expects the window sizes to go back whenever the screen resolution changes. I personally would be surprised to see the sizes change again. Also not all windows will change the size, most would just stay and keeping this information around is a rather large overhead.

Anyway I think we need to get the input from our userbase whether this is a required functionality. For this we use http://brainstorm.forum.kde.org nowadays.

as has been pointed out before, anything that temporarily reduces the desktop resolution completely messes up the geometry of everything in the workspace. the only clean way to get around this is creating separate user accounts and starting the full-screen apps in new sessions. that's typically ok, as those apps are by their nature quite isolated, but i'd hardly call that a solution.

(In reply to comment #11)
> Sorry for the late reply to this bug report which is actually not a bug, but
> a request for a new feature to keep track of the sizes of all windows when
> the resolution changes and restore to it.
From your point of view as a developer this may be a feature, I don't know, but as a user the current behavior is plain broken i.e. a bug.

> 
> I'm sorry to say but this is unlikely to be added. To me there is no
> indication that such a feature is in fact required, that our user base
> expects the window sizes to go back whenever the screen resolution changes.
Huh? I don't expect any sizes to change in an arbitrary way or whatever, I expect the previous state(s) to be _restored_. After all you also change sizes when switching down to a new resolution, so why wouldn't you restore sizes when switching back? Actually _this_ is surpising (and annoying)!

Btw. closing this with Resolved/Wontfix without further discussion doesn't feel like that you care what your users think. Obviously there are several people which see this as a problem, so it deserves to be taken serious. If you don't want to fix this or see a need to, fine. But this doesn't mean it's irrelevant and has to be closed!

(In reply to comment #13)
> Btw. closing this with Resolved/Wontfix without further discussion doesn't
> feel like that you care what your users think. Obviously there are several
> people which see this as a problem, so it deserves to be taken serious. If
> you don't want to fix this or see a need to, fine. But this doesn't mean
> it's irrelevant and has to be closed!
Fair enough, so let's have a look at it:
* bug reported eight years ago
* bug has 6 votes
* bug has 13 comments
* bug has 5 people in CC
* bug has 1 duplicate

KDE has millions of users. I do not see any indication that this is a feature required by a larger userbase and bugzilla is completely unsuited to figure out what the userbase expects. Because of that I added the link to the brainstorm section of our forum. Unfortunately we cannot implement each and every feature a user wishes. We have to decide what really matters for our userbase.

Now of course we care about our users and one of the things I consider important is to be honest. Given the data we have in this report there is no indication that this is a required feature which means that it does not have any priority in our product planing. This can also be seen by the fact that the request has been open for eight years. I think it is important to state that we won't implement the feature and because of that the feature request is set to WONTFIX. Keeping feature requests open and not implementing them gives the signal to the userbase that we don't care and users complain about the fact that we don't "fix bugs". Unfortunately we have had a rather large backlog of open requests resulting in feature requests being open for years. I'm very sorry about this fact and do my best that this will not happen in future again.

The thing that I found the most annoying, and was probably the reason why I started following this bug, was that after returning to the original resolution I would often find myself with a number of windows that were still the same width as before, but where the height now took up the entire screen. My only guess is that in the lower resolution, the window did touch both the top and the bottom of the screen and kwin tried to preserve that.

But I don't know if kwin still does that, or indeed if it ever happened outside of the Debian packages. I'm currently going through an Xfce phase so I can't easily test it.

> The thing that I found the most annoying, and was probably the reason why I
> started following this bug, was that after returning to the original
> resolution I would often find myself with a number of windows that were
> still the same width as before, but where the height now took up the entire
> screen. My only guess is that in the lower resolution, the window did touch
> both the top and the bottom of the screen and kwin tried to preserve that.
What you describe is a completely different bug which has nothing to do with 
this feature request, though if the feature request gets implemented the bug 
would maybe be hidden.

We prefer to fix bugs and not implement hacks to hide bugs.

What is actually the use case which should be solved with this feature request? Do I understand correctly that it is for playing games which need a different resolution?

i can imagine that switching to a smaller resolution when temporarily moving the desktop to an external display (e.g., a projector) could have a similar effect. one could argue that this qualifies as Doing It Wrong, though.

once upon a time, xawtv was also switching resolutions. as it did that with the xvidmode extension and not via xrandr, the virtual desktop size did not actually change due do that, so it had no impact on the geometry. one should check what it does nowadays. in the day of high-performance video overlays and fixed-resolution displays, video mode switching for tv doesn't seem too useful in the first place.

The use case in general is everything using xrandr to temporarily change resolution. In particular for me that would be games. Especially older ones which don't run in a higher resolution. Also I had this problem when connecting a projector to my laptop in mirror mode (I couldn't connect it as second screen, so I had to mirror the main screen and thus temporarily reduce it's resolution). Back then also TV apps used to be an issue, but that's probably not the case anymore. And you should also have this problem when rotating monitors (which support this), as here width or height shrink as well.

Something else: you always talk about a "feature" to implement. This is IMHO already the wrong approach at this issue. It destroys something, the window layout. Thus from the users POV it's a bug. Fixing the layout every time is an annoying job if you have a few windows. For me so much that I don't run games anymore which don't support the native resolution. Either I use a second account or boot into Windows. Ironically due to that I currently don't hit the bug anymore ;) But as written above that's hardly a solution.

(In reply to comment #19)
> The use case in general is everything using xrandr to temporarily change
> resolution. In particular for me that would be games. Especially older ones
> which don't run in a higher resolution. Also I had this problem when
> connecting a projector to my laptop in mirror mode (I couldn't connect it as
> second screen, so I had to mirror the main screen and thus temporarily
> reduce it's resolution). Back then also TV apps used to be an issue, but
> that's probably not the case anymore. And you should also have this problem
> when rotating monitors (which support this), as here width or height shrink
> as well.
So in summary we have three possible use cases:
1. Old (!) games
2. clone to projector
3. pivot

The only one I consider as valid is number 2, though this becomes less and less as a problem as it's quite some time ago that I have seen a projector with less than 1280x1024.

Why are the others not valid?
For 1 there are very good alternative solutions like using a second XServer also using Xephyr should work and even running a Virtual Machine (no hardware access required) should render quite good results. Especially a second XServer comes handy as it automatically ensures that you don't have a window manager conflicting, don't have a compositor and so on. For German readers there's a nice wiki page for it: http://wiki.ubuntuusers.de/Eigener_XServer_für_Spiele

Another very handy solution is to use Activities. When switching to the gaming activity all other applications can be stopped and restored when switching back to your work activity.

Rotating screens is something I have hardly seen using in real. If at all the screen is rotated permanently. Of course on form factor tablet that's different, but there we maximize all windows.
> 
> Something else: you always talk about a "feature" to implement. This is IMHO
> already the wrong approach at this issue. It destroys something, the window
> layout. Thus from the users POV it's a bug. Fixing the layout every time is
> an annoying job if you have a few windows.
From Wikipedia: "A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways."
Given this we don't have a software bug here. The application works correctly when reducing the resolution and going back. It completely behaves in the intended way and produces the expected result (size of windows not changed to previous size when switching back resolution).

What this report is about is to change the intended way of handling restoring the screen resolution. All changes of the intended behavior are feature requests from a developer point of view. That's why it is set to feature requests. That some missing features might appear as bugs to the users is a completely different thing. But from a technical point of view we just don't have any defect in the software here.

(In reply to comment #20)
> So in summary we have three possible use cases:
> 1. Old (!) games
Not necessarily. If your machine/graphics card is not powerful enough, you may choose to run especially new games at a lower than native resolution (especially with todays big monitors) in order to activate more effects.

> 2. clone to projector
> The only one I consider as valid is number 2, though this becomes less and
> less as a problem as it's quite some time ago that I have seen a projector
> with less than 1280x1024.
Even this may be smaller than the main screens resolution.

> 
> Why are the others not valid?
> For 1 there are very good alternative solutions like using a second XServer
> also using Xephyr should work and even running a Virtual Machine (no
> hardware access required) should render quite good results. Especially a
> second XServer comes handy as it automatically ensures that you don't have a
> window manager conflicting, don't have a compositor and so on. For German
> readers there's a nice wiki page for it:
> http://wiki.ubuntuusers.de/Eigener_XServer_für_Spiele
Without going into details, in my eyes these aren't good solutions, but only more or less good workarounds, adding more levels of complexity in terms of performance and handling. Far away from "plug and play". Leave alone if they actually solve the problem.

> 
> Another very handy solution is to use Activities. When switching to the
> gaming activity all other applications can be stopped and restored when
> switching back to your work activity.
Well yes, this might be a good idea anyway to save resources for the game. However, as much as I love the concept behind activities, they are still not really usable up to now. And even provided it works, this requires the user to manually suspend _all_ activites, and he should not forget it as otherwise -> boom. And it's not really an instant thing.

> 
> Rotating screens is something I have hardly seen using in real. If at all
> the screen is rotated permanently. 
Don't know, this just came to my mind.

> From Wikipedia: "A software bug is the common term used to describe an
> error, flaw, mistake, failure, or fault in a computer program or system that
> produces an incorrect or unexpected result, or causes it to behave in
> unintended ways."
> Given this we don't have a software bug here. 
Well, lets see: The user starts a game, and when he returns he obviously expects everything to be like before. The user might not even be aware that the resolution is switched, leave alone having explicitly commanded it. But when he returns the window layout is busted. So from the users POV we have a flaw that produces and unexpected result. It also behaves in an unintended way. So we have a bug :)

> 
> What this report is about is to change the intended way of handling
> restoring the screen resolution. All changes of the intended behavior are
> feature requests from a developer point of view. That's why it is set to
> feature requests. That some missing features might appear as bugs to the
> users is a completely different thing. But from a technical point of view we
> just don't have any defect in the software here.
Ok, fine. So we have some discrepancy here how the issue appears to the user and the developer. I obviously talk about the users POV here. It just seemed weird to me talking about this as a "feature". 

Anyway the problem is actually not that you technically declared it as feature/wishlist, but that you denied it to be a relevant problem all together and closed it with "wontfix". 

I'm not talking about persistently keeping layout information forever, and when you switch resolutions half a year later to get some long forgotton layout restored! This would be surprising of course. I'm only talking about temporary changes of resolution. And as you only get what you had some limited time ago, I don't see how this would be surprising. On the contrary.

Regarding your arguments that it doesn't affect many users or is open for a long time: a) this doesn't change that there actually is a problem and b) for me this is just a piece to the puzzle why gaming under Linux is unattractive. Currently I avoid it, so that I don't hit this bug. Others might do the same for one or the other reason and thus not complain. Also I understand that it's probably not a sexy thing to fix this, compared to say window effects.

Git commit f3a9f5f0e5a73300ddd35faa1dc5b2d7cae6894a by Thomas Lübking.
Committed on 11/04/2012 at 18:18.
Pushed by luebking into branch 'master'.

merge geom_pretile & geom_restore
remove some patch bodies
checkWorkspacePosition on geom_restore
reviewed-by: graesslin

M  +0    -1    kwin/client.cpp
M  +0    -1    kwin/client.h
M  +21   -26   kwin/geometry.cpp
M  +1    -1    kwin/manage.cpp

http://commits.kde.org/kde-workspace/f3a9f5f0e5a73300ddd35faa1dc5b2d7cae6894a

@Thomas: does this mean you fixed the issue (or implemented the feature, depending how one sees it)? I just wonder because you resolved it with "worksforme"...

the patch uses the last explicit (user/app) size to checkWorkspacePosition(), ie. if you change the screensize (therefore get an auto-resize), LEAVE THE WINDOW ALONE and then change the screensize back, the window geometry remains effectively untouched.

The moment however where you just pick the window to move it around few pixels, that's the new wanted size.

This is the only sane way to read the users mind about what he wants (the workspace position check is NOT up for negotiation) and what i read from the recent spam in my inbox, this is all about such very specific and now covered case ("gaming")

Tracking window geometries across several screensizes (as seems suggested by the bug title and OP) is imo however not a viable option and would almost certainly lead to false positive behavior (unwanted restorage)

The way you decribe it this sound exactly like a perfectly fine solution for the majority of cases. Very cool, thanks!!

*** Bug 278122 has been marked as a duplicate of this bug. ***

*** Bug 161325 has been marked as a duplicate of this bug. ***