Tiled windows are centered wrt to the center of the screen and do not take struts into account. If I have a wide panel on one of the screen edges (e.g. a deskbar), the window tiled next to it will be narrower than window tiled at the other edge. IMHO the tiling should use a center of available area, not center of the whole screen.
*** Bug 9644 has been marked as a duplicate of this bug. ***
Created attachment 4943 Patch to correct the bug This patch fixes the bug at hand (done over 4.10): ( everything done inside clientNewMaxSize() ) The tiling was using the whole screen coordinates and then cutting the area that overlapped with the pannels with clientMaxSpace(). Now, clientMaxSpace() is called first to get the space of the screen that is free from panels. Afterwards the tiling works over that space. + Minor thing: tmp_h and tmp_w for the rigth/bottom tiles are now calculated as the remaining space that is not taken by the up/left window tile space (if the number of avaliable pixels wasn't even, 1 would be wasted): that is, for TILE_DOWN instead of tmp_h = full_h/2; is now tmp_h = full_h - full_h/ 2; + Another minor thing (cleanup): Lines 3118 to 3121 seemed to be some kind of leftover(?): not used by anything afterwards. I removed them. I checked the patched version on my computer and a virtual machine, seems to work fine with changing number of panes and 1 or 2 monitors.
Created attachment 5512 Take account of panels reserved space for tilling Hello, Your patch work as expected on my system. Thanks! I'm totally agree with this: "that is, for TILE_DOWN instead of tmp_h = full_h/2; is now tmp_h = full_h - full_h/ 2;" However, If you remove lines 3118 to 3121 alone, tmp_h will not be initialised in some part of the code; and this is a source of memory leak. We should avoid this I think. Eventually, it is even possible to remove tmp_* completely, we don't even need to use them. I've submit a patch with such modifications.
Have you tested how this interacts with multimonitor setups with different sized monitors? Especially L-shaped configurations seem to have issues with struts. The whole struts mechanism is not really multimonitor aware at all, so I am a little bit worried this might have really bad side-effects...
See for example https://bugzilla.xfce.org/show_bug.cgi?id=10625 for what can happen if you test against struts from another monitor (and there isn't a way to tell which monitor struts belong to). Having menus open half way down the screen... if windows started doing that, it would be bad.
Created attachment 5594 screenshot without the patch and 2 monitors
Created attachment 5595 screenshot with the patch and 2 monitors
At least with what I tried here, it seems to work equally bad with and without my patch (over 4.10) with 2 monitors. (I played a bit with different dispay and panel positions and different amount of panels and it seemed always reasonable) See the screenshots attached
Pushed, thanks!