Hi,
Here are a bunch of questions ;-)
First, a background point. Owen and I had a long thread with Kevin
Martin a couple years ago (which was in private mail I think,
unfortunately). Anyway, the claim I was making then was that Xinerama is
overloaded to mean at least two things:
a) "I have one big monitor that happens to be made up of multiple LCD
panels / CRTs" - e.g. a video wall, is the extreme case
b) "I have two monitors and wish to be able to move windows between
them" - most commonly a plain dual-head or triple-head setup
When we talk about "Xinerama support" in the window manager and widget
toolkit, normally it means to act as if Xinerama is case b). That is,
the WM will do things like interpret FULLSCREEN as for only one monitor;
put DOCK windows on only one monitor; maximize to only one monitor; and
so forth.
All of this "Xinerama support" is busted if we are really in case a).
Anyway, my claim at the time was that X should just claim to have a
single monitor in case a), that is, apps have no interest in the
Xinerama info in case a), because the multiple monitors are really a
hardware implementation detail and not of interest. But at the very
least, we might want some kind of global property (set by e.g. the
desktop environment) that would tell the WM and the toolkit to ignore
Xinerama.
So second, why does FULLSCREEN go to only one monitor; it's because
we're in case b), "Xinerama support," and assuming that the two monitors
are supposed to be more or less separate. Common use-cases here include
having a status display such as a bunch of stock tickers or server
status readouts on one monitor and having your email/etc. on the other,
or just having email/web on one and programming on the other, or whatever.
Third, what is the case with VMWare? I'm guessing VMWare is totally
weird in that it's essentially doing hardware configuration - assign one
monitor to the VM and another monitor to the host, or something? Maybe
you can walk through the rough use-case and what your configuration GUI
for this might be like.
I'm having trouble thinking of something other than VMWare that might
want the hint you proposed, is why I'm calling it weird... doesn't mean
we can't do this hint, just that we shouldn't overload it with other
user-cases that aren't the same.
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.
Can anyone come up with a use case (other than VMWare) that would need
to force fullscreen to all monitors in case b)?
Fifth, I guess we could complicate things by allowing combinations of a)
and b) - "these two monitors form one monitor and this third monitor is
separate"
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"
Finally, what is the interaction with dynamic changes... metacity
reloads the xinerama info when it gets configure notify on the root
window iirc... I think xrandr can dynamically change the xinerama info.
It seems like there's a race created with the FULLSCREEN_MONITORS
property. This may be a minor problem though.
Havoc
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
