Re: RFC: FULLSCREEN_MONITORS property

["Elijah Newren" <newren gmail com>]

On 5/20/07, David Trowbridge <trowbrds gmail com> wrote:
> > 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)
>
> I'd say "on a monitor covered by the main window."  If possible, the one which
> the mouse is on.

That doesn't work as a (complete) solution.  I missed the same point
in my last email, which Lubos pointed out.  To quote him on this
topic, addressing which monitor to place dialogs of such windows on:

"And, if you're tempted to immediately give the (probably correct)
answer that on the active one, which one would that be? And no, the
one with the mouse doesn't count, as soon as one throws it away and
uses only keyboard for a while."

> > 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.
>
> I can't alt+drag a fullscreened window with metacity right now.  I don't think there's any
> specification that says that window managers aren't allowed to do that, though.

I'd count that as a bug (or at least missing feature) in metacity.
There's nothing technically stopping us from implementing it (just
time constraints), and it's one that I'd particularly like to address.
However, the FULLSCREEN_MONITOR proposal would introduce a technical
hurdle for this feature.  I don't like that.

> > 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?
>
> It would warp, at least with the implementation I wrote against metacity.  I don't think it's
> unreasonable to expect that an application which uses this hint will update it before
> setting _NET_WM_FULLSCREEN.
>
> > 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
>
> Sounds fine.

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?)


Elijah