Hi, David Trowbridge wrote: > As far as I can tell, reading through this again, people seem to be > generally happy with the idea of a FULLSCREEN_MONITORS hint > per-window.
Reading back over it, the only thing is I'm not sure I agree with Lubos that it should only affect FULLSCREEN. Let's put it this way - for vmware, where do you want dialogs to open (I know you can force-override from the app, but assuming you don't do that and let the WM place them, over what area should they be centered) It seems like there are xinerama considerations other than dialog location but I'm blanking on it right now. Oh, maximization I guess, in addition to fullscreen - should that follow this hint? Generally speaking the name FULLSCREEN_MONITORS just seems very not semantic to me. That is, if I have a question about how the WM should interpret it, I don't really know what the answer is, since I'm not sure what this hint means about the app at a high level. Here's another question - what happens if the user moves the app to another monitor that isn't a FULLSCREEN_MONITOR (and the app is fullscreen?) - metacity might allow that unless we also implement some kind of "fullscreen lock" behavior. Well, we allow it for maximized windows anyway, don't remember for fullscreen. Or if the app is not fullscreen and not on a FULLSCREEN_MONITOR and it gets fullscreened, it would warp to the FULLSCREEN_MONITOR? That seems a little weird. Would the app generally have to keep updating the FULLSCREEN_MONITOR to the monitor it's currently on? Now I'm wanting to say the hint should be a client message + hint combo like _NET_WM_STATE, i.e. - property sets the initial map value - WM updates the property after map - after map, app can change it via client message > Is this actually the case, and if so, what happens next? We need a patch to the spec DocBook, then if there are no improvements to the exact wording, someone can commit it (I'm not sure who has commit access these days but surely someone on the list does ;-)) In the spec text I'd be sure to cover some of the questions such as I have in this mail since all the implementations will need to know. We should probably then be willing to change the spec if the first couple WMs to implement it encounter problems. Havoc _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
