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
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
