On Monday 26 of November 2007, Havoc Pennington wrote: > 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 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).
SetInputFocus is something different - it does something, it sets the focus. Setting a property does not change a window geometry. > 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. The state is what the window geometry is. And almost nobody should care about what it actually is: - e.g. video-playing apps could use this property to play video either on one monitor or all (I know Xine has such option), but they don't really care what the result is, they should just use the geometry they get from the WM (as ICCCM says). - for the WM there's no difference - pagers don't care either, they simply show geometry (besides, the property applies only if the window is fullscreened, so bye-bye simple logic) - apps like VMWare that possibly could care already have the logic for setting right values for the property, so getting it the other way around shouldn't be difficult. Moreover they're supposed to try to cope with whatever geometry they get, just like everybody else (ICCCM again) Therefore I support the opinion that it should be just a one-way request like e.g. setting _NET_WM_NAME. > To sum up: > - allows WM or pager to have UI to modify fullscreen monitor state That does not depend on it. The WM can do it regardless and pager can set the property. > - allows WM to support a global default FULLSCREEN_MONITORS > for movies and presentations that don't set it Again, that does not depend on it. > (note: should patch spec to suggest not setting it to use > the default) Agreed here. In fact, probably part of the reason why I think it should be just a request and not a state is that I'd like to keep it what it should be - special case, not something everybody uses. > - allows app to figure out whether the WM is honoring its > FULLSCREEN_MONITORS hint If they really care that much, they can figure out from the geometry. The fact that they shouldn't care and this being asynchronous however IMHO makes this point void. VMWare people: What will happen if the WM will not honour the request? -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http//www.suse.cz _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list