
On Friday, January 22, 2016 1:54:21 AM MSK you wrote:
On Fri, Jan 22, 2016 at 1:48 AM, Bogdan Sinitsyn
wrote: On Friday, January 22, 2016 1:43:04 AM MSK Brandon Allbery wrote:
On Fri, Jan 22, 2016 at 12:46 AM, Daniel Wagner
wrote: It should be possible to find out what geometry the window is asking
for.
You could use that to decide whether the requested geometry is "big enough" to put full-screen or not. From looking at the source of `doFloat` in xmonad-core, I would guess `liftX . floatLocation` will give you the requested geometry in a `ManageHook`-friendly way.
fwiw I tracked down a problem with my xmonad.hs to an apparent bug in
this
which probably plays into the various reports of fullscreen windows
having
the wrong size when the default borderWidth is nonzero. Haven't looked at the code yet, but be aware that you may need to add 2*borderWidth conf to both height and width to get the correct window size.
Wouldn't it be better to set border width from fullscreenEventHook?
That's not the point. floatLocation misreports the requested position and size of *all* windows, because whoever wrote it didn't realize that the border is *inside* the window. And the default border is always set before ManageHook etc. run, which is also before the _NET_WM_STATE_FULLSCREEN change can be communicated to us whether it's by being set at ManageHook time or by sending a message to the root window.
This does imply that if you decide to remove the border, you need to adjust the position and size again to compensate.
If we remove the border before sending any full-screen message to layout, we don't need to adjust the position and size because layout will calculate window size after we remove border. -- Bogdan Sinitsyn