Re: Review: FULLSCREEN_MONITORS Hint

Hi,

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 case mentioned in the original thread in April was that the WM could 
offer a UI for dragging the window between monitors (as we do for 
maximized windows). e.g. maybe you can Alt+drag the fullscreen window.
In that case, or if the WM or pager in any other way offers UI for 
changing fullscreen monitors, we'd need the _NET_WM_STATE-style approach.

Another possibility: it might be annoying to treat 1-monitor fullscreen 
as a special case; the WM might want to just set FULLSCREEN_MONITORS to 
the single monitor the app is on, in that case, if the app did not set 
FULLSCREEN_MONITORS itself.

If we require the WM to do that, then the app could also avoid special 
cases; it could be written to simply watch and respond to 
FULLSCREEN_MONITORS, thus adapting to any WM-originated or 
pager-originated changes in the property.

A WM might even have a global default. For example, I could say "for any 
app not specifying FULLSCREEN_MONITORS, fullscreen that app to these two 
monitors." Seems pretty useful for the presentation/movie case.

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).

It's possible the question of "what happens when the Xinerama config 
changes?" matters here too, though I guess it probably doesn't - the 
answer to that is probably just to document that which of the app or WM 
is supposed to deal with it.

Anyway, overall I think the _NET_WM_STATE style approach is simply 
cleaner and more future-safe, even if nobody has immediate plans to 
support WM or pager changes to this property.

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.

It just makes sense to me that a persistent property is the state, and 
requests to change the state are a one-time client message. vs. using a 
persistent property to mean a request to change a state, where the state 
is then internal to the WM.

To sum up:
  - allows WM or pager to have UI to modify fullscreen monitor state
  - allows WM to support a global default FULLSCREEN_MONITORS
    for movies and presentations that don't set it
    (note: should patch spec to suggest not setting it to use
     the default)
  - allows app to figure out whether the WM is honoring its
    FULLSCREEN_MONITORS hint
  - conceptually, distinguishes between the state and the request to
    change state

Havoc