I am running an Xfce desktop on a Debian/testing system, with xfwm4 4.6.2. Whenever I start a full-screen game that runs at a lower resolution than the normal desktop, I find on exiting the game that all my windows have been shifted to the upper-left-hand corner of the screen. I believe xfwm4 is failing to distinguish between desktop resolution changes (where it would be reasonable to shift window positions to keep them visible), and fullscreen-app resolution changes (where it is not). I suspect this behavior may be a side effect of the fix for Bug #5795, because earlier releases of xfwm4 (though I can't say at what exact point things changed) certainly did not have it.
Hello. The same happens also for desktop icons. Their positions change with low-res fullscreen games and I have to restore them each time I exit the game.
(In reply to comment #1) > Hello. The same happens also for desktop icons. Their positions change with > low-res fullscreen games and I have to restore them each time I exit the game. That's unrelated, icons are managed by the desktop
Ok. I created a new Bug 6653 for the icons http://bugzilla.xfce.org/show_bug.cgi?id=6653
I've confirmed that the bug is absent in 4.6.0, and present in 4.6.1.
Fixed in git master
Unfortunately, this bug isn't quite licked yet. I'm using xfwm4 version 4.8.2, on Ubuntu Oneiric. When a low-resolution game is loaded, windows that are partially within the smaller screen area are not touched; however, windows and desktop icons that are entirely outside this area are moved in until they are partly inside. Three screen shots that illustrate the problem are forthcoming.
Created attachment 3967 Screenshot: Before game This is a screenshot of a stock Xubuntu 11.10 desktop, with Xfce 4.8, running inside VirtualBox. I've set up three windows, and three desktop icons at the bottom and right-side corners of the screen. There is also a terminal window occupying the center area.
Created attachment 3968 Screenshot: Game This is Kobo Deluxe, running at 640x480 resolution. It is an addictive, fast-paced shoot-'em-up.
Created attachment 3969 Screenshot: After game The xlogo windows have been moved so that they are partly inside the 640x480 area (at the top-left corner of the screen) in which the game was running. The desktop icons have not only moved in, they have completely shuffled around the order of the Home/FileSystem/Trash icons that were already at the top-left. This bug is fixed when the "after" desktop looks the same as "before."
Unfortunately this is the best I can come up with. The game changing resolution is the same as the user changing resolution, and it's the role of the window manager to make sure that all windows remain accessible when the screen resolution has been changed, or when a monitor has been disabled (in a dual head setup). Without this, changing resolution would make windows out of reach of the user, which is really not a good solution. Keeping the window accessible can be done in two different ways: 1. Make the entire window visible 2. Do not move the window to be fully visible, but make it so a tiny part of the window still remains visible so the user can still click and move it. Previously, solution 1. was chosen in any case, thus moving all windows to the top left corner. Now, solution 1. is chosen only if a monitor is removed. And solution 2. is chosen for simple resolution changes, such as the one that happens when running a game is low-res. Now, I believe that avoiding the replacement entirely is not desirable, again, I think it's the role of the window manager to make sure that all windows remain accessible to the user in any circumstances (as much as possible, of course). Changing that would be a (serious) regression. I am therefore closing this bug as wontfix, what we have now is what I think it should be.
Created attachment 3979 Patch against xfwm4 git master Okay, so I pulled out my debugger, and poked around a bit in the code, eventually focusing on clientScreenResize(). I see that there aren't any obvious properties on the game window to indicate how it is special. But looking at it, at least two conditions always seem to be the case: 1. The window has a width/height exactly equal to the screen's new width/height; 2. The window is marked as non-resizable. With that, I've put together a first-cut patch that adds a check to clientScreenResize(): if any window meets the above conditions, then presume that it's a low-res game/app of some kind, and skip the clientConfigure()ing loop. The conditions could probably be narrowed further, and the check may or may not be better done before the "revalidate client struts" loop. But so far, this has worked perfectly for all the games I like to play. Those XLogo windows only move when I change the desktop resolution manually.
Unfortunately, that's a hack tbh, the same kind of things I am trying to remove (see git commit 9982c00b [1]) Trying to guess and adapt to the apps/windows is not a good solution in the long term. A better approach would be to memorize the previous location before resizing the screen, and restore that location when the resolution changes back. If in the mean time the user has moved the window, the previous location should be cleared (means the user want the window in a new location, the position should not be reverted tin that case) [1] http://git.xfce.org/xfce/xfwm4/commit/?id=9982c00b3b7f6423faf9fe4a18cb92e85ce11c8f
Note, the patch is fairly simple, I would possibly consider including such a patch if well written.
I imagine the best solution would be for game windows to set an actual hint so that the WM can tell what's going on. Currently, a new window appears, and then there's a screen-size change, but very little appears to connect the two from the WM's point of view. I don't think any standard exists for such a hint, however, and it'll be a long time before we see one. The attached patch has the advantage of being self-contained and to the point. But if you'd rather have the new fields in Client, and the necessary logic in clientScreenResize() and a couple other places, then I'll work on implementing a patch along the lines you describe.
Created attachment 3980 Patch against xfwm4 git master Okay, here's a first-draft patch implementing your approach. It does the trick for the xlogo windows. However, maximized windows see needless churn from doing things this way. Is it workable to have these windows not be notified of the size change until the user would actually see them?
fixed in git master (different patch though)
Thanks for getting a fix in---look forward to trying it out.