
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

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
On Thu, Jan 21, 2016 at 1:30 AM, 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 xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

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? On Thursday, January 21, 2016 9:46:31 PM MSK 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.
~d
On Thu, Jan 21, 2016 at 1:30 AM, Thomas Järvstrand
wrote:
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 xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
-- Bogdan Sinitsyn

On Fri, Jan 22, 2016 at 1:28 AM, 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. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

På Fri, 22 Jan 2016 07:47:14 +0100, skrev Brandon Allbery
On Fri, Jan 22, 2016 at 1:28 AM, Bogdan Sinitsyn
wrote: 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. -- Audun Skaugen

On Fri, Jan 22, 2016 at 4:16 AM, 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 s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Fri, Jan 22, 2016 at 12:46 AM, 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. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

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? -- Bogdan Sinitsyn

On Fri, Jan 22, 2016 at 1:48 AM, Bogdan Sinitsyn
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
On Friday, January 22, 2016 1:43:04 AM MSK Brandon Allbery wrote: 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. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

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

On Fri, Jan 22, 2016 at 2:05 AM, 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. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Friday, January 22, 2016 9:22:27 AM MSK you wrote:
On Fri, Jan 22, 2016 at 2:05 AM, Bogdan Sinitsyn
wrote: 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. -- Bogdan Sinitsyn

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
fre 22 jan. 2016 kl 16:03 skrev Bogdan Sinitsyn
On Friday, January 22, 2016 9:22:27 AM MSK you wrote:
On Fri, Jan 22, 2016 at 2:05 AM, Bogdan Sinitsyn < bogdan.sinitsyn@gmail.com> wrote:
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.
-- Bogdan Sinitsyn _______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
participants (5)
-
Audun Skaugen
-
Bogdan Sinitsyn
-
Brandon Allbery
-
Daniel Wagner
-
Thomas Järvstrand