Re: RFC: FULLSCREEN_MONITORS property

[Havoc Pennington <hp redhat com>]

Hi,

Elijah Newren wrote:
> I'm not following the suggestion, Havoc.  How does the WM update it?
> If you're referring to a hint like the original, as I was inferring,
> then the hint is the monitors to which the app says that the WM should
> fullscreen the app window.  How then does the WM update this hint,
> i.e. how does it magically guess which monitors are okay to fullscreen
> to if it doesn't use the app hint?  (And if we can do that, why do we
> need a hint from the app in the first place?)

I don't think the _NET_WM_STATE-style approach introduces the problems 
here, the problems arise if you say that the WM can try to be smart 
about or participate in the fullscreen monitors decision (by allowing 
alt+drag, or by fullscreening to the current monitor instead of 
fullscreen monitors, or by having a menu item to "stretch this app over 
the monitor to the right also," or whatever).

If you allow the WM (or pager) to e.g. allow the user to alt+drag the 
window from monitors 1,2 to monitors 2,3 or something like that, then 
you need the _NET_WM_STATE approach to do that without races, you can't 
just have a free-for-all where app and WM can both change the property 
directly, or where the WM ignores the property sometimes.

The _NET_WM_STATE approach does not preclude a "non-interfering" WM that 
changes FULLSCREEN_MONITORS only when the app itself asks it to via 
client message. It does however *allow* an "interfering" WM.

If we don't go the _NET_WM_STATE route, then the WM in effect *must* be 
"non-interfering" - it MUST accept the FULLSCREEN_MONITORS property in 
all cases and never change it or ignore it. That may be right but seems 
inflexible.

What makes sense to me (right this minute anyway) is to treat 
FULLSCREEN_MONITORS just like the other state info such as MAXIMIZED. 
The WM can have UI or keybindings or something to change it, the app can 
have defaults, and the app would typically accept any state set by the 
WM, and also save the current state when the app exits, and restore it 
on app startup.

It does seem like the best UI for this would be in an app dialog (since 
it's only useful to do this for some apps), with only "hidden" UI like 
alt+drag in the WM. But that doesn't preclude the _NET_WM_STATE-style 
approach - it just means the dialog in the app would either set the hint 
(before map) or send the client message (after map), and that the app 
would then need to track the current property state and update its 
dialog/saved-state accordingly if it changes. IOW just like MAXIMIZED, 
the canonical copy of the state is kept by the WM for mapped windows and 
kept by the app for withdrawn windows, and when the app exits (withdraws 
a window) the app is responsible for persisting the last-known state.

It's possible that going more top-down on the problem and doing some 
quick sketches of all the involved dialogs, menu items, keybindings, 
etc. would make it clearer what to do?

Havoc