awesome

Welcome to awesome bug tracking system.
Tasklist

FS#764 - Maximized window state becomes confused when moved between screens

Attached to Project: awesome
Opened by Chris AtLee (catlee) - Friday, 07 May 2010, 15:33 GMT
Last edited by Uli Schlachter (psychon) - Friday, 11 April 2014, 09:16 GMT
Task Type Bug Report
Category Core
Status Unconfirmed   Reopened
Assigned To No-one
Operating System Linux
Severity Low
Priority Normal
Reported Version 3.4.4
Due in Version 3.5.6
Due Date Undecided
Percent Complete 0%
Votes 5
Private No

Details

Using awesome debian/3.4.4-1 (Jet Sex)

I have an nvidia card, and I have two monitors set up as one contiguous desktop (TwinView). The two monitors have different sizes.

I usually have firefox open on my left monitor in a maximized state. If I open a new firefox window via Ctrl-N, and try to move it to the 2nd screen, this is what happens:

1) Ctrl-N: new window appears on left monitor in a maximized state

2) cmd-o (awful.client.movetoscreen): the window moves to the right monitor. Its geometry is unchanged however. Also, the window appears in the window list at the top of the *LEFT* monitor. The window list indicates that it's still maximized, but the window is not filling up the right monitor.

3) With the new window focused, cmd-m (bound to a function that flips c.maximized_horizontal, and maximized_vertical):
The window jumps back to the left screen, and is now a regular tiled window.

4) cmd-o again: The window moves to the right screen, and is still tiled.

5) cmd-m again: The window is now properly maximized on the right screen, and shows up as expected in the right-screen's list of windows.
This task depends upon

Comment by Uli Schlachter (psychon) - Friday, 07 May 2010, 17:44 GMT
Looking at the code that actually handles "c.screen = s", it seems to be doing some black magic with fullscreen clients to ensure they are still fullscreen, but then doesn't actually do anything with the computed value (?). Also, I'm not 100% sure it calculates the geometry correctly...
Comment by Noé Rubinstein (Phlogistique) - Thursday, 05 May 2011, 10:27 GMT
Confirmed with 3.4.7.
Comment by Noé Rubinstein (Phlogistique) - Thursday, 05 May 2011, 10:31 GMT
Confirmed with 3.4.9.
Comment by Lauri Niskanen (Ape) - Tuesday, 21 May 2013, 07:01 GMT
I also have this issue with 3.5.1.
Comment by Uli Schlachter (psychon) - Friday, 14 June 2013, 12:09 GMT
First duplicate (and it only took three years):  FS#1158 
Comment by xgdgsc (xgdgsc) - Friday, 14 June 2013, 12:44 GMT
There is a difference between this one and my bug report. In this one the window appear at the window list on the wrong screen, and jumps back with Mod4-m. I think my report might be easier to reproduce and resolve. So it' s not strictly a duplicate. Just hope you will resolve both.
Comment by Uli Schlachter (psychon) - Thursday, 06 March 2014, 21:08 GMT
commit 8cf48d1fe84177ae9a3448379691ca0fc4bc9b90
Author: Uli Schlachter <psychon@znc.in>
Date: Thu Mar 6 22:08:00 2014 +0100

Revert "awful.ewmh: Enforce client geometry (FS#764,FS#1216)"

This reverts commit 20afb26080cd34691c67720fef396bed5a0be237.

The commit caused endless loops with tracebacks like this (shortened):

lib/awful/ewmh.lua.in:122: in function <lib/awful/ewmh.lua.in:117>
[C]: in function 'geometry'
lib/awful/ewmh.lua.in:122: in function <lib/awful/ewmh.lua.in:117>
[C]: in function 'geometry'
lib/awful/ewmh.lua.in:122: in function <lib/awful/ewmh.lua.in:117>
[C]: in function 'geometry'
Comment by Daniel Hahler (blueyed) - Monday, 17 March 2014, 01:59 GMT
Maximized and fullscreen clients do not appear to get handled at all in screen_client_moveto.
Code: https://github.com/awesomeWM/awesome/blob/master/screen.c#L381-399

@Uli: apart from that, do you plan to re-roll/-try the patch from above, that got reverted?
Comment by Uli Schlachter (psychon) - Monday, 17 March 2014, 09:03 GMT
I still have no idea why that code tries to force clients to fit into the screen. That seems a bit weird to me.

For doing something about maximized and fullscreen clients: What should that code do with them? It can't deny resizes for them or "force" a specific size because handling these states is implemented in lua.
Why they are handled in lua instead of C I can't give a good reason for. I don't think anyone will ever want to change the meaning of "fullscreen" or "maximized"...

So... reverting the move-that-thing-to-lua commit and make the C code enforce this thing more "seriously"?. That should also fix the endless loops that my patch caused for sure... Dunno.
Comment by Daniel Hahler (blueyed) - Wednesday, 19 March 2014, 04:12 GMT
> I still have no idea why that code tries to force clients to fit into the screen. That seems a bit weird to me.

And it might even be causing the strange issues that pop up when moving clients to another screen, where you have to move them back and forth once and/or (un)maximize them inbetween.

> So... reverting the move-that-thing-to-lua commit and make the C code enforce this thing more "seriously"?. That should also fix the endless loops that my patch caused for sure... Dunno.

Sounds reasonable then.

Do you have a reference to the "move-that-thing-to-lua commit"?
Would it be possible to just trigger the same code that maximizes a client or makes it fullscreen after moving it to another screen? (Like if the user initiated it)
I guess that's what you are referring to with the code that is in LUA now?
Comment by Uli Schlachter (psychon) - Wednesday, 19 March 2014, 09:14 GMT
> Do you have a reference to the "move-that-thing-to-lua commit"?

commit 38edc5809755b4623b30bcb1838360d29d86b789
Author: Julien Danjou <julien@danjou.info>
Date: Mon Oct 5 17:13:29 2009 +0200

client: implements maximized and fullscreen requests with Lua


Reverting that one (I am already afraid of the conflicts) should definitely make fullscreen clients behave again since screen_client_moveto() will handle them. Dunno about maximized.

Loading...