Re: RFC: FULLSCREEN_MONITORS property

[Lubos Lunak <l lunak suse cz>]

On Friday 09 of March 2007, Havoc Pennington wrote:
> Hi,
>
> Elijah Newren wrote:
> > Hi,
> >
> > On 3/9/07, David Trowbridge <trowbrds gmail com> wrote:
> > <snip>
> >
> >> Back to my requirements for this -- I really, *really* don't want users
> >> to have to think about configuring "virtual" monitors in order to do
> >> something like have a VM across two of their three heads and still
> >> interact with their host on the third.  Apps that want to take advantage
> >> of more than a single screen will work best when they know about
> >> xinerama, and chances are that I, or the flight simulator programmer, or
> >> the graphics app hacker will know better about their individual usage of
> >> multi-monitor windows than the window manager or the user.
> >
> > So, your hint is an application specific override to the current
> > handling of xinerama only.

 I think a WM setting would do as well (enabling strict geometry in KWin's 
window-specific settings could do this, although I'm too lazy to try for 
real :) ), but I suppose a hint apps could set would be simpler for users. 
After all, if people start misusing it, I can still interpret the strict 
geometry setting the other way around. So this is on okay from me too.


> Current handling of xinerama or current handling of fullscreen? e.g. if
> vmware opens a dialog, should the WM center it on one monitor or across
> the two vmware covers?

 On one, we're still talking b) and you don't want the dialog to be split 
between two monitors. However this might make sense e.g. for maximization. 
But allowing this flag to apply to more than just fullscreen brings up more 
questions (what if I want it to apply only to fullscreen?), so I'd probably 
keep this fullscreen-only until somebody asks for this. I've also already 
seen requests for apps being able to ask for multiple-monitors fullscreen but 
I don't remember asking for anything else.

> David, I think your comment that the app hacker knows better applies
> exactly to the extent that the behavior change is only in one app. If
> two apps need to coordinate, then the app hacker may know better, but
> isn't in a position to implement the behavior.
>
> It does make sense to me that certain apps (games, vmware) might say
> "cover multiple monitors" where the multiple monitors are distinct
> spaces (what I called "b)" originally) for all other apps.

 Why? I don't see a single reason why VMWare should be able to change how 
Konqueror goes fullscreen.

> So I'd go 
> with Elijah and say the hint makes sense, though I'm not clear yet on
> whether it should cover only fullscreen behavior or all "xinerama
> awareness"
>
> I do think some of the other issues raised need addressing, but they
> appear orthogonal to this hint since this hint assumes case b) and
> doesn't take a position on how we distinguish a) and b)

 And do we need to take position on a)? As you said, in such case Xinerama 
settings should pretend there's no Xinerama.

> Perhaps there's a caveat that if we add a global hint to specify case
> a), this app-window-specific hint would need to match that overriden
> monitor layout rather than what the Xinerama extension reports.
>
> Hmm, another unrelated thought; is this hint really per-window or should
> it be on the group leader - seems to me we'll have to effectively figure
> out the xinerama request of the transient parent in order to place
> dialogs, anyhow.

 I'd say per-window.

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