Where to start? Implementing independent workspace switching with Xinerama

[Brian J. Tarricone]

On Wed, 18 Apr 2007 16:26:23 -0500 Don Christensen wrote:

>> Omari Stephens wrote:
>>> Olivier Fourdan wrote:
>>> ::snip? SNIP!::
>>>   
>>>> But anyhow, that would not make much sense. If you want to
>>>> haveindependent screens, simply don't use Xinerama;
>>>>     
>...
>>> To summarize, if there are 3 applications for which I may want to 
>>> look at some arbitrary pair of them simultaneously, this will
>>> require the ability to move windows between monitors.
>
>I'd like to have this ability, also.  I don't use Xinerama because
>I want to be able to switch workspaces independently on each monitor,
>and that is more important to me than being able to move application
>windows from one monitor to the other.
>
>Just to be clear, the difference between using two monitors in
>Xinerama and plain multi-head is that in Xinerama, the two monitors
>appear to be a single display (ie, :0.0), whereas in plain multi-head,
>they appear to be two different displays on the same server (ie, :0.0
>and :0.1).  In the Xinerama case, applications aren't aware in any
>sense that I know of that there is more than one monitor.

Well, they can be, using the same Xinerama API that the WM uses (or
using Gdk wrapper API such as gdk_screen_get_n_monitors() and
gdk_screen_get_monitor_geometry()).  But I'd say most of the time most
applications don't know anything about multiple screens.

The problem with switching workspaces independently with Xinerama is
that Xinerama makes all monitors inolved into one big screen.  Don't
look at it as having separate workspaces on each monitor that, for
Xinerama, are just arbitrarily "locked" together.  They're actually one
and the same workspace.

I suppose it would be possible to layer fake 'virtual' workspaces on
top of that, and have them correspond to just the single monitor, but
it would require changes to more than just the WM: xfdesktop would
break, the pager would break, the taskbar would break, and possibly
other DE-related apps would as well.  Doing this might also violate
some standards (probably NETWM, maybe even ICCM [but probably just the
former]).

>So another way to look at this, and perhaps an easier way (although
>I don't know X well enough to say if it's at all feasible), is that
>what is needed is a way to move windows from one display to another
>(ie, from :0.0 to :0.1).  A perfect solution would support windows
>straddling the displays, but an acceptable solution would be to
>have a "move this window to display N".
>
>Beyond the obvious problem of color depth, I'm not sure what kind
>of impediment there is to doing this.  Maybe the RnR stuff has
>removed some of the issues.

Yep, that would be nice, and there are even provisions in gtk for doing
display migration.  Unfortunately, it's not possible to say this will
work for every application.  It would probably work for most gtk
applications (assuming the application doesn't require changes, which
they may), but I don't know about Qt, Xt, Motif, etc.

I haven't looked into the new additions to the xrandr extension, but
it's possible something there could help.  Probably won't be generally
available for a while, though, especially since the 1.2 stuff appears
to need driver support.

	-brian