[xmonad] Yet another fullscreen thread...

[Thomas Järvstrand]

Hi!

I'm a happy xmonad user since a couple of years now. Previously I managed
to successfully set it up the way I wanted under Ubuntu using Gnome2 but
recently I decided I wanted to try something new and installed xfce
(xubuntu), under which I'm having some trouble setting the fullscreen
functionality which for some reason was working flawlessly under ubuntu
14.04.

I have problems getting fullscreen applications to work. Specifically
showing media. I have been able to apply the workaround to float VLC but
it's a bit annoying since I don't always want to have it fullscreen all the
time and I haven't been able to find a good way of switching back and
forth. In old Ubuntu 14.04 setup this was just working. In there any other
way to solve this than the doFullFloat for VLC?

BR
Thomas

[Daniel Wagner]

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.

~d

Post by Thomas Järvstrand
Hi!
I'm a happy xmonad user since a couple of years now. Previously I managed
to successfully set it up the way I wanted under Ubuntu using Gnome2 but
recently I decided I wanted to try something new and installed xfce
(xubuntu), under which I'm having some trouble setting the fullscreen
functionality which for some reason was working flawlessly under ubuntu
14.04.
I have problems getting fullscreen applications to work. Specifically
showing media. I have been able to apply the workaround to float VLC but
it's a bit annoying since I don't always want to have it fullscreen all the
time and I haven't been able to find a good way of switching back and
forth. In old Ubuntu 14.04 setup this was just working. In there any other
way to solve this than the doFullFloat for VLC?
BR
Thomas
_______________________________________________
xmonad mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Bogdan Sinitsyn]

Windows usually request full-screen by setting _NET_WM_STATE_FULLSCREEN, don't
they? Anyway, for me full-screen VLC works using fullscreenSupport from
X.L.Fullscreen without any workarounds. Thomas, do you have fullscreenSupport
in your configuration?

Post by Daniel Wagner
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.
~d

Post by Thomas Järvstrand
Hi!
I'm a happy xmonad user since a couple of years now. Previously I managed
to successfully set it up the way I wanted under Ubuntu using Gnome2 but
recently I decided I wanted to try something new and installed xfce
(xubuntu), under which I'm having some trouble setting the fullscreen
functionality which for some reason was working flawlessly under ubuntu
14.04.
I have problems getting fullscreen applications to work. Specifically
showing media. I have been able to apply the workaround to float VLC but
it's a bit annoying since I don't always want to have it fullscreen all the
time and I haven't been able to find a good way of switching back and
forth. In old Ubuntu 14.04 setup this was just working. In there any other
way to solve this than the doFullFloat for VLC?
BR
Thomas
_______________________________________________
xmonad mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Brandon Allbery]

Post by Bogdan Sinitsyn
Windows usually request full-screen by setting _NET_WM_STATE_FULLSCREEN, don't
they?

Some programs (notably Firefox) check _NET_SUPPORTED and use the old way
(just open a fixed size window, size obtained from the size of the Xinerama
screen, or from the root window if there isn't Xinerama info); we do not
put _NET_WM_STATE_FULLSCREEN in _NET_SUPPORTED because it's an optional
component that needs to be added to handleEventHook and layoutHook, and
neither can be introspected to see if it should be advertised or not.

[Audun Skaugen]

PÃ¥ Fri, 22 Jan 2016 07:47:14 +0100, skrev Brandon Allbery

On Fri, Jan 22, 2016 at 1:28 AM, Bogdan Sinitsyn

Post by Bogdan Sinitsyn
Windows usually request full-screen by setting
_NET_WM_STATE_FULLSCREEN, don't
they?

Some programs (notably Firefox) check _NET_SUPPORTED and use the old way
(just open a fixed size window, size obtained from the size of >the
Xinerama screen, or from the root window if there isn't Xinerama info);
we do not put _NET_WM_STATE_FULLSCREEN in _NET_SUPPORTED >because it's
an optional component that needs to be added to handleEventHook and
layoutHook, and neither can be introspected to see if >it should be
advertised or not.

Author of X.L.Fullscreen here. Would it be a good idea to provide a
startupHook in the module which sets the _NET_SUPPORTED property? So
people who use the layout modifiers could broadcast this support to client
applications.

[Brandon Allbery]

Post by Audun Skaugen
Author of X.L.Fullscreen here. Would it be a good idea to provide a
startupHook in the module which sets the _NET_SUPPORTED property? So people
who use the layout modifiers could broadcast this support to client
applications.

I'm working on a redesign of EWMH that will make this stuff more sensible.
That said, it might be useful as a stopgap, since (a) the rewrite is going
slowly (b) backward compatibility is Hard and I may just ditch it.

[Brandon Allbery]

Post by Daniel Wagner
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.

[Bogdan Sinitsyn]

Post by Brandon Allbery

Post by Daniel Wagner
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?

[Brandon Allbery]

Post by Thomas Järvstrand

Post by Brandon Allbery

Post by Daniel Wagner
It should be possible to find out what geometry the window is asking

for.

Post by Brandon Allbery

Post by Daniel Wagner
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

Post by Brandon Allbery
which probably plays into the various reports of fullscreen windows

having

Post by Brandon Allbery
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.

[Bogdan Sinitsyn]

Post by Brandon Allbery

Post by Thomas Järvstrand

Post by Brandon Allbery

Post by Daniel Wagner
It should be possible to find out what geometry the window is asking

for.

Post by Brandon Allbery

Post by Daniel Wagner
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

Post by Brandon Allbery
which probably plays into the various reports of fullscreen windows

having

Post by Brandon Allbery
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.

[Brandon Allbery]

Post by Bogdan Sinitsyn
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.

We are supposed to guess beforehand that a normal window that gets
fullscreened (this is the case that requires the handleEventHook) needs its
border removed? Or that we should do so after it is removed from the tile
but before we receive the message telling us to remove it from the tile and
fullscreen it?

I'm really not sure what window model you are using, but it doesn't seem to
be X11's.

[Bogdan Sinitsyn]

Post by Brandon Allbery

Post by Bogdan Sinitsyn
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.

We are supposed to guess beforehand that a normal window that gets
fullscreened (this is the case that requires the handleEventHook) needs its
border removed? Or that we should do so after it is removed from the tile
but before we receive the message telling us to remove it from the tile and
fullscreen it?
I'm really not sure what window model you are using, but it doesn't seem to
be X11's.

Event hook for full-screen windows already exists in X.L.Fullscreen. If we add
removing and re-applying borders just before sending messages to layout in
that hook(X.L.Fullscreen.fullscreenEventHook, it'll work fine.

[Thomas Järvstrand]

Thanks everyone for you replies!

I'm not exactly what you would call well versed in Haskell but with some
clues from above and some googling I think I managed to solve it with the
below change:
- , handleEventHook = ewmhDesktopsEventHook
+ , handleEventHook = ewmhDesktopsEventHook <+> fullscreenEventHook

Thomas

Post by Bogdan Sinitsyn

On Fri, Jan 22, 2016 at 2:05 AM, Bogdan Sinitsyn <

Post by Bogdan Sinitsyn
If we remove the border before sending any full-screen message to

layout,

Post by Bogdan Sinitsyn
we
don't need to adjust the position and size because layout will

calculate

Post by Bogdan Sinitsyn
window size after we remove border.

We are supposed to guess beforehand that a normal window that gets
fullscreened (this is the case that requires the handleEventHook) needs

its

border removed? Or that we should do so after it is removed from the tile
but before we receive the message telling us to remove it from the tile

and

fullscreen it?
I'm really not sure what window model you are using, but it doesn't seem

to

be X11's.

Event hook for full-screen windows already exists in X.L.Fullscreen. If we add
removing and re-applying borders just before sending messages to layout in
that hook(X.L.Fullscreen.fullscreenEventHook, it'll work fine.
--
Bogdan Sinitsyn
_______________________________________________
xmonad mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad