Re: RFC: FULLSCREEN_MONITORS property
- From: "David Trowbridge" <trowbrds gmail com>
- To: "Havoc Pennington" <hp redhat com>
- Cc: wm-spec-list gnome org, Lubos Lunak <l lunak suse cz>
- Subject: Re: RFC: FULLSCREEN_MONITORS property
- Date: Sun, 20 May 2007 22:53:36 -0700
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.
Oh, maximization I guess, in addition to fullscreen - should that follow
this hint?
Maybe there's a use case for maximizing over multiple monitors. I personally
don't know of any.
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.
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.
-David
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]