Re: RFC: FULLSCREEN_MONITORS property

["David Trowbridge" <trowbrds gmail com>]

There seem to be a number of ideas interwoven throughout your last email, and
try as I might, I can't seem to compose a cogent reply inline.  I'll try to
respond to each point individually, with the hope that I'm not misunderstanding
or missing anything.


> > What should the basic behavior of the desktop be?

We currently have a well understood behavior, and I think it maps quite well to
users' expectations: each physical monitor on the host is reflected within the
xinerama configuration.  If a window exists on a monitor, it will maximize to
the bounds of that screen.  Its dialogs will appear on the same screen, etc.  As
you noted, there are just a few "exceptions to the global setting"

> > What are the exceptions?
- Games: I think this one is pretty obvious.
- VMware: This is potentially less obvious, but I think it's actually a lot like
 the games use case.  The vmware window may want to span across multiple
 monitors, but a user doesn't want that to impact any other applications they
 happen to be running.
- Blender: This was just me racking my brain for other applications which
 request that a window cover multiple monitors.  It's pretty typical in the
 graphics application space (of which blender is the only linux representative
 that I know of) to request as many pixels as possible, since in a lot of
 cases, an artist just wants to live inside that environment.

Two things strike me about all of these use cases.  First, they are all within
fullscreen mode.  This may be an accident, or it may be a useful observation.
Second, I think these cases are at their most well behaved when the applications
in question have some xinerama awareness built-in.  A flight sim would want to
draw things such that the splits between monitors didn't occur in the middle of
your altitude control.  VMware passes the monitor information through to the
guest OS to really make it look like you're not using a virtual machine.
Blender might want to add edge resistance on its internal area splits to make it
easier to lay out your workspace to fit your screens.

> > Should this be a global hint, and allow applications to change the xinerama
> > layout to suit their needs?

I think this is a huge can of worms.  What if I have a spreadsheet maximized on
screen 0, and I ask vmware to go into fullscreen across both screens 0 and 1?
Does my spreadsheet now get maximized to both heads along with it?  What happens
to my panel windows?  A lot (read: all) of applications are not written with
this sort of behavior in mind.  randr++ will force things like gnome-panel to
take it into account, but I think the chances that an application would do
something that the user didn't want are pretty high.



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.


-David

On 3/4/07, Havoc Pennington <hp redhat com> wrote:
> Elijah Newren wrote:
> >> Fourth, excluding VMWare, what hints are missing...
> >> we could add _NET_WM_FULLSCREEN_ALL_MONITORS or something, but I think
> >> that might be wrong. It might be more correct to implement a property,
> >> to be honored by both WMs and toolkits, that essentially says "ignore
> >> Xinerama, this is case a) not case b)" - and then the existing
> >> _NET_WM_FULLSCREEN would cover all the monitors, and other "Xinerama
> >> awareness" would also be disabled.
> >
> > Do we really want a screen global property rather than a
> > window-specific property?
>
> We definitely need a global prop also, if I understand your question -
> if I have a single virtual monitor (made up of multiple LCD panels or
> CRTs) then I want all the "fullscreen" buttons and options in my desktop
> and my apps to automatically go to the whole monitor.
>
> If I have multiple monitors, then I want all apps to automatically go to
> only one monitor.
>
> This is a global config thing, and it should be configured the same
> place I set up Xinerama in the first place.
>
> App-specific hints would be only to override the default because an app
> was special somehow.
>
> Otherwise every app would need to contain xinerama config, right?
>
> >> Sixth, I can imagine wanting to switch between a) and b) depending on
> >> context; maybe you play your flight simulator with your three monitors
> >> as one big screen, but when doing anything else you want three separate
> >> monitors. This quickly becomes a serious programming and UI nightmare...
> >> perhaps the proposed hint would fix it though by providing an "escape
> >> hatch"
> >
> > I can see that this would be a nightmare if the hints were global to
> > the screen rather than specific to each window.  I don't see any
> > problems with the latter, right now.  Can others think of any?
>
> To be honest I don't see how per-window even works - metacity, for
> example, needs to globally decide whether to be "xinerama aware" - if
> apps disagree on whether there are multiple conceptual monitors or just
> one, then who knows what "xinerama aware" should do.
>
> Per-window works to make exceptions, but there has to be a basic
> behavior for the overall desktop... what area do windows maximize to,
> what area are dialogs centered in, etc.
>
> Exceptions to the global setting might be:
>   - you want "one big monitor" for certain games or something but
>     not for productivity (note this is probably a user decision,
>     not something the game developer should hardcode)
>   - vmware... maybe. seems to me the vmware case may be the same
>     as putting your stock ticker readouts on one head and your
>     applications on another; the only thing is vmware wants to
>     have the config GUI for it in the vmware app itself. But
>     stuff would break if for example metacity thought there
>     was one big monitor, and vmware wanted to be on only one
>     of them; then e.g. metacity would maximize other apps
>     to cover up vmware. So vmware may want to change the global
>     setup? If we had a global hint, if a user wanted vmware on
>     two monitors and native host on a third, they'd just fullscreen
>     vmware on the two (after globally configuring those two as one
>     virtual monitor)
>   - I don't understand the blender case well enough
>
> Writing the above made me realize, FULLSCREEN_MONITORS is probably wrong
> because xinerama awareness goes beyond the fullscreen hint. e.g. what
> about vmware's dialogs, which monitors should the WM consider when
> placing them? what about maximization? etc. So maybe the hint is just
> plain MONITORS.
>
> Thinking about the user-visible behavior of the whole desktop, I'm
> wondering if we're talking about inherently global state (the monitor
> arrangement and which groups are conceptually single monitors) because
> the state involves interactions between a bunch of different apps and
> the WM itself, and everyone has to agree at any given point in time.
> (i.e. to do fullscreen across all monitors, you'd have to just nuke the
> separate monitors while your app was focused)
>
> That may not be true, I do think *most* apps have to agree at any given
> point though, at least, the WM, panel, and all normal apps that don't
> have their own UI for tweaking which monitors they span. "Exception"
> apps may have app-specific setup that overrides, or something.
>
> Havoc