Re: Sawfish and dual head : state of the art

[Jonathan Koren <jkoren cs siu edu>]

On Mon, 13 Dec 2004, Jerome wrote:

> It's quite difficult to find any information on the net about dual
> screen handling with X in general.
> One would easily find how to set up a dual screen config in
> /etx/X11:XF86Config-4 but what about WMs ?

Unlike a lot of people who weigh in on xinerama, I actually run it every 
day.  First thing you need to make clear is that xinerama makes the all 
the monitors behave like one large monitor.  This means that only one X 
server and only one window manager running.  Windows can be dragged from 
monitor to monitor, and even span multiple monitors.

The other dual head setup uses a single X server and multiple window 
managers (one per monitor).  This setup is merely multihead, and IS NOT 
xinerama, and should NEVER EVER be confused with xinerama.  (This is 
an important point, and one that is close to my heart.)  This setup is 
strange and wierd, and is only used by strange and wierd people.  :)


> Sawfish offers 3 (2) ways to handle dual head setup :
> . sawfish --multihead :

I've never heard of this.  I've never heard of anyone using this.  It's 
not even listed as an option as of version 1.0.

> . sawfish & DISPLAY=:0.1 sawfish in .xinitrc :

This is what I understand people the strange and wierd people use.

[copying from the --multihead point]

> 	However it makes it possible to run 2 different SF on both heads.

What makes it possible to run multiple instances of the window manager is 
X.  When you start X you will get the grey stiple background on both 
monitors.  Or if you start X through some sort of proxy (i.e. gdm) you'll 
get the program on the monitor associated with DISPLAY=:0.0 and the grey 
stiple on the other monitors.

You mouse will be able to travel between the two monitors (since there's a 
single X server), but the window manager will not allow the windows to 
leave the monitor (more preceisely the display).  Legend has it, you 
can get windows to switch monitors by moving them from display to display 
using x2x.  Legend also says that some sawfish extension exists (or can 
readily be made) that will invoke x2x with the proper arguments when a 
window is dragged to the edge, not unlike moving a window between 
viewports.  (Viewports are NOT workspaces, but I digress.)

As you said, you start a window manager on the other displays by either 
setting the DISPLAY envrionment variable to the other monitor (e.g. :0.1) 
and runnig it from the command line as usual, or by passing
--display=<display> to sawfish.

> 	The SF are *really* independent, and you can't move a window from a
> 	head to the other. Some objects like files in file managers might
> 	move, useless-drag-n-drop-thingie-that-just-works (tm).

I'm not sure if this is true.  I haven't tried it, but I don't really see 
how it would work.  I'm not really up on the xdnd protocol though.

> 	Quite difficult to switch from one display to the other.

See the x2x stuff above.

> 	Ex: your mail/irc client, monitoring apps, all you need to keep an
> 	eye on, on 1 and the rest on the other.
> 	Very pratical for monitoring-like tasks.


Yes, yes that's what all the strange and wierd people say, but sticky 
windows and window avoidence (like what keeps gnome-panel from being 
covered when maximizing), does the same thing.

> . startx -- +xinerama and sawfish in .xinitrc :
> 	Your two+ head are now a huge composite desktop, sawfish is running
> 	on it as on a single head.
> 	You can drag n drop / move windows from a head to the other.
> 	You can cycle between windows on the two heads.
> 	Ex: Editor running on 1 and the result (pdf for latex,
> 	applications when coding, etc) on the other.
> 	Pratical to get extended thematic workspaces,


You are correct sir!


> *XINERAMA*
>
> Let's consider this setup (I tried not to use tabs, so it should display
> nicely) :
>
>         ________________________________
>        |             |                  |
>        |             |                  |
>        |             |                  |
>        |      1      |        2         |
>        |             |                  |
>        |_____________|                  |
>                      |                  |
>                      |                  |
>                      |__________________|
>
> Head 1 : 1024x768     (Laptop monitor)
> Head 2 : 1280x1024     (external LCD)
>
> *placement*
> Sawfish understands this setup as a large (1024+1280)x(1024) desktop and
> not really a composite.
> The main side effect is that some window are misplaced :
>
>         ________________________________
>        |             |                  |
>        |             |                  |
>        |             |                  |
>        |      1      |        2         |
>        |  ____       |                  |
>        |_| w  |______|                  |
>          |____|      |                  |
>                      |                  |
>                      |__________________|
>
> Sawfish seems to understand the space below 1 as free space and place
> windows on it.

This probably comes from sawfish's placement algorithm only using 
ScreenOfDisplay(), which returns information about the composite display, 
instead of examining the individual monitors' dimensions via
XineramaQueryScreens().

Now if this is true, the question is why does the maximizaion code do the 
right thing, since the change should have been made all at the same time?

> *borders*
> The limit between 1 and 2 is quite problematic. No window is initially
> drawn by SF on this limit however many apps are started in a very large
> mode, so that they cross the limit.

Maximizing the window should force it to the size of the current monitor. 
HOWEVER, if the window starts on the monitor it wasn't maximized on, then 
it gets the dimensions of the maximization, but retains the ability to 
move and resize (i.e. the difference between clicking "maximize" and 
simply dragging the window borders to fill the entire screen).  I think 
this is, or at least is related to, what you're describing.

I don't know a way around this.  Another anoyance related to this, is that 
placement methods are not tied to the individual monitors.  For example, 
my placement method is top-left.  This means that if my mouse is on the 
right monitor, and I spawn a new window, it is created on the left 
monitor.  Kind of annoying.  I should write some routine that performs the 
placement on the monitor that the mouse is currently on.  (Yet another 
thing for me to do in my copious free time.)

--
Jonathan Koren			World domination?  I'll leave that to the 
jkoren cs siu edu		religious nuts and the Republicans, thank you.
http://www.cs.siu.edu/~jkoren/		-- The Monarch, "Venture Brothers"