Re: RFC: FULLSCREEN_MONITORS property

[Havoc Pennington <hp redhat com>]

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