differentiate between floating and tiled in rects and only apply tileWindow to tiled windows

[incertia]

This addresses #81. There's not much to test but if this totally kills the behavior of floating windows let me know and I'll see what other workarounds I can put in.

Checklist

• I've read CONTRIBUTING.md

• I've confirmed these changes don't belong in xmonad-contrib instead

• I tested my changes with xmonad-testing

• I updated the CHANGES.md file

[liskin]

Doesn't kill them completely, moving and resizing using the mouse still works, but other changes to window size/location seem to be ignored:

• placeHook in manageHook is ignored
• W.float in a key binding is ignored ad well

Both of these are expected, I guess, as you removed the call that is meant to sync xmonad's view of window placement with the X server.

[incertia]

I can think about what to do with W.float. Maybe this means creating a version of tileWindow that does not affect the border and applying it to flt. placeHook should work as expected. The manage hook is composed somewhere in the f parameter of windows and is applied to the old set of windows and all further operations commence on the new value, ws, within the first few lines of windows.

[wedens]

I've applied this patch, but some dialogs are still displayed like this:

When I set border width to 0, it displays dialog properly:

[wedens]

Wait. For whatever reason recompiling and restarting xmonad was not enough. After reboot the problem is fixed (at least for this dialog).

[liskin]

@wedens Reboot shouldn't be needed, but just a recompile/restart may not be enough on a non-traditional distro like NixOS. I'd look that way. (But this is off-topic here.)

[geekosaur]

Mod-shift-space after restart?

…

On 6/11/20, Tomáš Janoušek ***@***.***> wrote: @wedens Reboot shouldn't be needed, but just a recompile/restart may not be enough on a non-traditional distro like NixOS. I'd look that way. (But this is off-topic here.) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #207 (comment)

-- brandon s allbery kf8nh allbery.b@gmail.com

[liskin]

Mod-shift-space after restart?

On NixOS the binary may end up in an entirely different location as the path is a hash of the sources that produced it...

[wedens]

Seems like this MR breaks moving floating windows with mod+left (default binding) mouse button. It moves the window and also resizes it.

[liskin]

Seems like this MR breaks moving floating windows with mod+left (default binding) mouse button. It moves the window and also resizes it.

That's a good point. Before this PR, RationalRect meant the same thing for all windows. After this PR, it suddenly means "outer window dimensions (incl border)" for tiled windows and "inner window dimensions (excl border)" for floating windows. So if you grab a tiled window and start moving it, it'll resize because its RationalRect suddenly means something else. And yeah I suppose it breaks moving floats as well because that uses X.Operations.float which invokes floatLocation and that adjusts for the border width, but now that RationalRect means something else that adjustment isn't good.

Anyway, I think a better fix for the issue (#198, rather than #81, because I don't think xmonad is ever going to become a reparenting WM that draws borders outside) would be to adjust the RationalRect in X.Operations.manage. That invokes floatLocation as well, but the border width correction doesn't actually happen because that window's border width is 0 at that point. We could tell floatLocation to correct for the future border width instead.

But then, we don't really know the border width is 0… it could well be something else if the window was created with a border. So perhaps an even better fix would be to adjust the floating RationalRect whenever the border width is changed. When the border width is set initially during managing the window we could get the previous border width, compare it to the border width being set, and adjust the floating RationalRect, if any. And the same thing at all the places in xmonad-contrib that change the border size.

It'll likely mess up fullscreen windows, especially games, somewhat, but I can't foresee how exactly. We'll have to try.

Another idea, possibly the simplest to implement, is to just add a manageHook that corrects for the difference in border widths. One could conditionally use this for ordinary floats and skip games/fullscreens as those won't end up having borders anyway.

[liskin]

Hm, but all these ideas of mine seem impossible to make play nice with https://xmonad.github.io/xmonad-docs/xmonad-contrib/XMonad-Layout-NoBorders.html. That's a bit unfortunate. And yeah, with RationalRect meaning "inner window dimensions (excl border)" for floats this problem goes away (as long as every border width change is followed by a refresh that does moveResizeWindow)…

[geekosaur]

Merge the Chrome hack to core? 😉

[liskin]

Merge the Chrome hack to core? 😉

That's a different issue. What I was talking about here is that X.L.NoBorders changes the border width a lot and the mechanics of whether a window ends up having a border or not are quite complex, so the only place we can reliably adjust the floating rect is X.L.NoBorders itself. But! All this border width adjustment happens in runLayout, and you can't mess with the floating rects in there, because runLayout is invoked from within windows.

We'd need to use something like https://xmonad.github.io/xmonad-docs/xmonad-contrib-0.18.0.9/XMonad-Util-ActionQueue.html (which was introduced for the implementation of https://xmonad.github.io/xmonad-docs/xmonad-contrib-0.18.0.9/XMonad-Hooks-BorderPerWindow.html, another border-related thingy, lol) to adjust the floating rects afterwards, which would double the already quite annoying flickering of X.L.NoBorders. And it's entirely possible this would result in endless loops, so we'd need a circuit-breaker somewhere.

It's just gets super ugly. I'll need to sleep on this.

[liskin]

(suppose now's the time to look at @LSLeary's pull requests as some of the problems I'm anticipating here are probably solved by the design changes in those PRs… this got out of hand quite quickly 🙂)