Re: RFC: FULLSCREEN_MONITORS property

[Lubos Lunak <l lunak suse cz>]

On Wednesday 18 of April 2007, Elijah Newren wrote:
> 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.

 Was that a request for the IDE being able to maximize its window in such a 
way or a for the user being able to maximize some window in such a way using 
the WM? I can see some point in apps asking for a special geometry in special 
cases but I don't see why maximization should be any app's business.

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

 Note that this brings another question: Where should the dialog be shown 
then? 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. Apps using this multi-screen hint would probably also have to 
provide this information somehow (internal focus/cursor position?).

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

 This would make more sense, but then the question is if the app handles 
moving between (xinerama) screens and the possible changes of geometry. Would 
VMWare handle such case?

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l lunak suse cz , l lunak kde org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz