Re: RFC: FULLSCREEN_MONITORS property

["Elijah Newren" <newren gmail com>]

On 4/10/07, Havoc Pennington <hp redhat com> wrote:
> 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.
<snip and pull a line out of order>
> Oh, maximization I guess, in addition to fullscreen - should that follow
> this hint?

I've seen at least bug report requesting a similar ability for
maximization (in particular for some IDE).  I'm not sure I'd see why
to support fullscreen but not maximization with such a hint.

> 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.

Actually, we already have a similar precedent that may be useful.  In
a dual-monitor xinerama system with metacity, we make desktop windows
(such as the one from nautilus) cover both monitors.  We got bug
reports when nautilus dialogs were split across xineramas.  Based on
that, I think the answer is that the FULLSCREEN_MONITORS hint (or
whatever we call it) should not be inherited by children.  Thus, the
behavior would be as Lubos suggested earlier: we would not want child
dialogs to be split across monitors and thus such dialogs wouldn't
necessarily be centered on their parent.

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

I think these are really good questions.  The current suggested hint
now bothers me because I can't see how to handle these.  Perhaps we
should instead have a
  _NET_WM_FULLSCREEN_AND_MAXIMIZATION_GEOMETRY
hint (or some better name with a similar meaning) which consists of a
pair of integers and defaults to 1x1.  1x1 means the window
fullscreens/maximizes to cover 1 monitor horizontally and 1 monitor
vertically.  2x1 would make the window cover both monitors in your
typical dual monitor xinerama case.  But having 2x1 would also make it
clear what to do if you had a three monitor setup and wanted to move
the maximized/fullscreen window.

Thoughts?

Elijah