Yet another fullscreen thread...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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



_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

Daniel Wagner-4
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad



_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

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?

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 <[hidden email]>
>
> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad


--
Bogdan Sinitsyn
_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

Brandon Allbery
In reply to this post by Daniel Wagner-4
On Fri, Jan 22, 2016 at 12:46 AM, Daniel Wagner <[hidden email]> 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.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

Brandon Allbery
In reply to this post by Bogdan Sinitsyn
On Fri, Jan 22, 2016 at 1:28 AM, Bogdan Sinitsyn <[hidden email]> 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.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

Bogdan Sinitsyn
In reply to this post by Brandon Allbery
On Friday, January 22, 2016 1:43:04 AM MSK Brandon Allbery wrote:

> On Fri, Jan 22, 2016 at 12:46 AM, Daniel Wagner <[hidden email]> 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
_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

Brandon Allbery
On Fri, Jan 22, 2016 at 1:48 AM, Bogdan Sinitsyn <[hidden email]> 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 <[hidden email]> 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.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
> 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 <[hidden email]> 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
_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

Audun Skaugen
In reply to this post by Brandon Allbery
På Fri, 22 Jan 2016 07:47:14 +0100, skrev Brandon Allbery <[hidden email]>:

On Fri, Jan 22, 2016 at 1:28 AM, Bogdan Sinitsyn <[hidden email]> 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

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

Brandon Allbery
On Fri, Jan 22, 2016 at 4:16 AM, Audun Skaugen <[hidden email]> wrote:
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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

Brandon Allbery
In reply to this post by Bogdan Sinitsyn
On Fri, Jan 22, 2016 at 2:05 AM, Bogdan Sinitsyn <[hidden email]> 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.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

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 <[hidden email]>
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Yet another fullscreen thread...

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

fre 22 jan. 2016 kl 16:03 skrev Bogdan Sinitsyn <[hidden email]>:
On Friday, January 22, 2016 9:22:27 AM MSK you wrote:
> On Fri, Jan 22, 2016 at 2:05 AM, Bogdan Sinitsyn <[hidden email]>
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad