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