[xmonad] Yet another fullscreen thread...

[Bogdan Sinitsyn]

On Friday, January 22, 2016 1:54:21 AM MSK you wrote:
> On Fri, Jan 22, 2016 at 1:48 AM, Bogdan Sinitsyn <bogdan.sinitsyn at gmail.com>
> 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 <dmwit at dmwit.com> 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