Re: Panel behaviour under Xinerama

[Havoc Pennington <hp redhat com>]

On Thu, May 08, 2003 at 03:54:59PM +0100, Bill Haneman wrote: 
> FWIW, the expectation when I was working on Xinerama-related stuff for
> SUN customers in the past was that "xinerama means one screen", i.e.
> apps should not in general do anything special when xinerama is on, and
> they should not try to "work around" the one-big-virtual-screen behavior
> that is the purpose of the xinerama extension.

Right. Red Hat has a couple of these "giant display array" customers
too.

While I believe that these customers originally motivated the Xinerama
work and still use it, it's also worth noting that on both Windows and
Mac the multiple monitor support is like Xinerama, not like X
multihead. I believe the Xinerama-style multihead should really be the
standard setup for multiple monitors. There's no reason to prohibit
moving windows between monitors.

When people talk about "Xinerama support" in the window manager, gdm,
GTK, etc. they always mean "Xinerama as multihead" - not centering
dialogs across monitor boundaries, and so forth. For giant display
array you really want the WM, toolkit, and so forth to ignore
Xinerama.

When I was using Xinerama with the 2.2 panel I'm pretty sure it
created a separate panel for each monitor - did that behavior break
now? I do think it's right. We should treat Xinerama basically the
same as multihead.

I don't think anyone runs a desktop on a giant screen, other than
briefly in order to start their presentation or fire up their big map
in the war room. So for that usage of Xinerama we really just want
GNOME to ignore Xinerama entirely. When we are "Xinerama aware" we
should be targetting the "nice UI multihead" case. That's when
Xinerama is relevant to the desktop.

Ideally, the new X.org Xinerama spec would export a setting telling us
whether the screen was a single virtual monitor or intended to be
multihead-equivalent. However, getting useful things like this out of
the current X community is a bit of a nightmare, so the best we could
do probably is to document something on freedesktop.org.

Havoc