When tiling a maximised window, you would expect later clicking on the maximise button on the title bar to maximise the window again. This is not the case. It actually performs an unmaximise action. To re-produce, open a window and maximise it. Drag to left or right to tile the window. Now click the maximise button and the window unmaximises. It would seem when a maximised window is tiled, the WNCK_WINDOW_IS_MAXIMIZED flag is not unset, leading xfwm4 to believe it is still maximised and perform an ummaximise next time the button is clicked. Cheers.
<EDIT> This does not happen with all windows. Using xfce4-terminal and thunar, these apps display the correct behaviour. Using mousepad or firefox display the incorrect behaviour. </EDIT>
xfwm4 does not use nor depend on libwnck. Tiling in xfwm4 works in conjuction with (partial) maximization, either vertically or horizontally. Better check the EWMH flags for maximization, if those do not match the actual state, then there could be a bug.
Apologies for the delay in responding. After some more intense investigation on my end, it would appear to not be a bug as such, more intended behaviour but un-expected behaviour (from the user standpoint) from tiling, as follows: Using the following bitmask for window states: STATE_MINIMIZED = 1 STATE_MAXIMIZED_HORIZONTALLY = 2 STATE_MAXIMIZED_VERTICALLY = 4 STATE_SHADED = 8 STATE_SKIP_PAGER = 16 STATE_SKIP_TASKLIST = 32 STATE_STICKY = 64 STATE_HIDDEN = 128 STATE_FULLSCREEN = 256 STATE_DEMANDS_ATTENTION = 512 STATE_URGENT = 1024 STATE_ABOVE = 2048 STATE_BELOW = 4196 I get the following behaviour from all windows (my mistake in thinking thunar behaved differently to firefox etc, turns out to just be intended, but un-expected behaviour of xfwm4) 1. Start window normal: 0 (bit mask) 2. Maximize window: 6 3. Move the window: 0 window resizes to state before maximize 4. Maximzise window: 6 5. Move window to left or right to tile: 0 only an unmaximize is triggered, when window reaches left or right egde, a vertical maximize is not triggered (unsure if this is intended or cannot be avoided but I would expect the state to change to 4 and the window be tiled to the left or right) 6. Release window and then move to left or right to tile: 4 7. Move window: 0 8. Move window to left or right to tile: 4 9. Maximize window button: 0 the window reverts to normal state and the position is at the last remembered co-ordinates before the vertical maximize in step 8 was triggered. I would expect the window to maximize here (bitmask 6) as even though the window is maximized in one direction, the logical state would be normal (bit mask 0), but users would not consider a vertical (or horizontal) only maximized state (bitmasks 2 and 4) to be a maximized window. I would suggest the next logical step (for a user) from a bitmask of 2 or 4 to be 6. The positioning of the window in this circumstance could be considered a bug, as the position is restored to the last remembered co-ordinates prior to the vertical or horizontal maximize is triggered. This results in the majority of the window now being off screen (especially if horizontally tiled at the bottom of the screen - it is nearly 100% off screen), or at the top of the screen (the title bar is now under my panel requiring an ALT + LEFT CLICK to move the window). So from the above, I guess I am really suggesting a modification in behaviour as follows: From step 9 above - clicking the maximize button on a window that is only maximized in one direction (bitmask 2 or 4) should change state to maximized (bit mask 6). From step 5 above - dragging a maximized (bitmask 6) window should change state to normal (bitmask 0) as it does, but if that drag continues to a screen edge, then a state change to vertically or horizontally mazimized should trigger (bit masks 2 or 4). Of course, if these state changes are not possible (due to limitations of some sort), then may I suggest the state change to normal (bitmask 0) should also trigger a smart placement of the window either to the centre of the screen or as set in the xfwm4 smart placement settings, preventing situations of the window being placed almost entirely off screen. Cheers.
Created attachment 5502 Fix ToggleMaximize fn when window is solely maximized verticaly or horizontaly Hello, I've made this patch when I worked on my custom package. This should fix this issue. The problem seem to come from to the ToggleMaximize function which do not maximize window when they are partially maximized horizontally or vertically.
Created attachment 5548 Fix ToggleMaximize fn when window is solely maximized verticaly or horizontaly I found another related issue: When the user try to restore maximized window that was previously tiled, the previous position was not restored correctly. The new patch also fix this issue.
Thank you very for working on this issue. I just reported it on Ubuntu Launchpad: https://bugs.launchpad.net/bugs/1397922 Thanks again for your time and work, Yvan
I finally had time to look at this patch and test it out. It works great and fixes both issues in question. Thanks for doing the hard work, Cédric! http://git.xfce.org/xfce/xfwm4/commit/?id=d577e6195478241241e534d92daffe34f69a088b
Actually the described behaviour was on purpose but I understand it was confusing users so it's fine to change that.
*** Bug 8766 has been marked as a duplicate of this bug. ***