Re: Review: FULLSCREEN_MONITORS Hint

[Havoc Pennington <hp redhat com>]

Hi,

I don't think the pager could set the FULLSCREEN_MONITORS property 
directly. There can be only one client (app or WM) able to modify a 
property at a time, IMO. If we want pagers to be able to change this, we 
should use the client message, or it's just asking for race conditions 
and even infinite loops.

Look at the _NET_WM_NAME example as you mention. _NET_WM_NAME is defined 
as what the _app_ requested, so any non-app client changing it is just 
wrong. In fact, we have a property _NET_WM_VISIBLE_NAME for exactly this 
reason, because we distinguish the state (_NET_WM_VISIBLE_NAME) from the 
app's request (_NET_WM_NAME). We had to add VISIBLE_NAME because people 
end up wanting to know not only what was requested, but what the WM did.

Geometry is not a full substitute because it's a separate state from 
FULLSCREEN_MONITORS, much as STATE_FULLSCREEN itself (or maximized or 
minimized) are separate states from geometry (even though they affect 
geometry).

An example of why it's a separate state is that a FULLSCREEN_MONITORS 
state exists even when the window is not in fact fullscreen. If for 
example I had a FULLSCREEN_MONITORS UI in the pager, it would be 
legitimate to allow setting the FULLSCREEN_MONITORS for a movie app, 
even when that app was not in fullscreen mode at the time. And to have a 
UI I need to know the current state.

In theory, a WM could also use a 
not-exactly-the-same-size-as-the-monitor geometry for a fullscreen app. 
For example I think it would be legitimate to have some kind of border 
or toolbar even in fullscreen mode, if a WM really felt like it, or 
legitimate to honor the size increment (grid) hints of something like a 
terminal app even in fullscreen mode.

As you say the app (or pager) should always adapt to the geometry it 
gets, but that is for geometry-related matters. For any app or pager UI 
that displayed or allowed you to edit FULLSCREEN_MONITORS, it would be 
wrong to use the geometry; instead, the FULLSCREEN_MONITORS values 
should be used, since that state will exist even when the geometry does 
not match it, due to e.g. not being in fullscreen state, or just some 
strange WM policy.

The request+state-property approach is a superset of a just-a-property 
approach that allows several additional things to work right, if those 
things ever come up. That makes it more future-safe. It seems to have 
little downside to do things in a more future-safe way.

If we don't do request+state-property, then down the line we might end 
up adding the equivalent of _NET_WM_VISIBLE_NAME, something like 
_NET_WM_ACTUAL_FULLSCREEN_MONITORS.

Havoc