Re: Review: FULLSCREEN_MONITORS Hint

[Lubos Lunak <l lunak suse cz>]

On Monday 26 of November 2007, Havoc Pennington wrote:
> Mark Tiefenbruck wrote:
> >> A model where the WM maintains the property (when window is mapped) and
> >> the client has to ask to change it, allows the WM to modify the property
> >> without races - similar to how we handle _NET_WM_STATE.
> >
> > Part of my assumption was that the WM doesn't need to modify this
> > property at all. I can't think of a reason why it would, since this is
> > purely a request from the client for specific treatment.
...
> The NET_WM_STATE-style setup also allows the WM to intercept and deny
> FULLSCREEN_MONITORS requests. In the past, the cases where we don't have
> WM "redirection" of a request have often been a problem (SetInputFocus
> most notably).

 SetInputFocus is something different - it does something, it sets the focus. 
Setting a property does not change a window geometry.

> I guess it hinges on whether you consider the FULLSCREEN_MONITORS
> property to be a state ("the monitors the app is fullscreened on") or a
> hint about a state ("the monitors the app would like to be fullscreened
> on, with current state stored separately by the WM"). I think it's more
> robust if the property _is_ the state (as with _NET_WM_STATE), rather
> than the app's request, since then everyone can share knowledge of what
> the state is.

 The state is what the window geometry is. And almost nobody should care about 
what it actually is:
- e.g. video-playing apps could use this property to play video either on one 
monitor or all (I know Xine has such option), but they don't really care what 
the result is, they should just use the geometry they get from the WM (as 
ICCCM says).
- for the WM there's no difference
- pagers don't care either, they simply show geometry (besides, the property 
applies only if the window is fullscreened, so bye-bye simple logic)
- apps like VMWare that possibly could care already have the logic for setting 
right values for the property, so getting it the other way around shouldn't 
be difficult. Moreover they're supposed to try to cope with whatever geometry 
they get, just like everybody else (ICCCM again)

 Therefore I support the opinion that it should be just a one-way request like 
e.g. setting _NET_WM_NAME.

> To sum up:
>   - allows WM or pager to have UI to modify fullscreen monitor state

 That does not depend on it. The WM can do it regardless and pager can set the 
property.

>   - allows WM to support a global default FULLSCREEN_MONITORS
>     for movies and presentations that don't set it

 Again, that does not depend on it.

>     (note: should patch spec to suggest not setting it to use
>      the default)

 Agreed here. In fact, probably part of the reason why I think it should be 
just a request and not a state is that I'd like to keep it what it should 
be - special case, not something everybody uses.

>   - allows app to figure out whether the WM is honoring its
>     FULLSCREEN_MONITORS hint

 If they really care that much, they can figure out from the geometry. The 
fact that they shouldn't care and this being asynchronous however IMHO makes 
this point void.

 VMWare people: What will happen if the WM will not honour the request?

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l lunak suse cz , l lunak kde org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz