libxfcegui4's xinerama wrapper

[Brian J. Tarricone]

Jasper Huijsmans wrote:

> I was wondering, how about using the GdkScreen API? It is available 
> since gtk 2.2, so we could use it for Xfce 4.2. Are there any problems 
> with that?

i started using some of it with xfdesktop, but frankly i find it 
somewhat confusing.  i just looked at it again, and i think ive figured 
it out.  here's how i understand it:

GdkDisplayManager: this is weird, and i don't think we care about it, so 
i'll skip it.

GdkDisplay: logically, this maps to a single X display, coinciding 
(usually) with a single instance of an X server.  somewhat confusing the 
issue is gdk_display_open(), which can open a connection to an arbitrary 
GdkDisplay (identified by a char* name).  i don't think we need to worry 
about it; assuming a single display via gdk_display_get_default() should 
be sufficient.

GdkScreen:  this seems to have two somewhat-related meanings:

* non-xinerama mode: a single GdkScreen maps to a unique monitor (or 
head, whatever you want to call it).  you can get these by using 
gdk_display_get_screen(gdpy, num).  you can discover the number of such 
screens on the display by calling gdk_display_get_n_screens(gdpy).  the 
functions gdk_screen_get_width(gscrn) and gdk_screen_get_height(gscrn) 
return the size of the display area on the specified monitor (head).

* xinerama mode: the GdkScreen is essentially a singleton object, and 
there is one GdkScreen for the default GdkDisplay.  this GdkScreen 
represents the entire screen real estate controlled by the xinerama 
display, made up of all the monitors (heads) connected to the 
GdkDisplay.  calling gdk_screen_get_width(gscrn) or 
gdk_screen_get_height(gscrn) on the singleton GdkScreen should return 
the maximum width or height of the arranged xinerama setup.

now, for xinerama mode, it looks like we can go one layer deeper: 
gdk_screen_get_n_monitors() and gdk_screen_get_monitor_geometry().  i 
would guess that the former returns the number of physical monitors that 
make up the xinerama screen.  the latter should return the position and 
size of the numbered monitor within the xinerama screen.

also of note are the gdk_spawn_on_screen() family of functions, which 
can be used to start a program on a particular GdkScreen.  this is 
useful for non-xinerama mode, but, for xinerama mode, it doesn't appear 
that we can decide what monitor the app should end up on.  the WM will 
handle it using its normal algorithm (but using a coordinate space that 
encompasses several physical monitors).

this all seems to make some amount of sense to me, but, as i've never 
actually tried it, and the docs seem somewhat sparse, i can't be sure.  
feel free to correct me.

xfdesktop already uses gdk_display_get_n_screens() and 
gdk_screen_get_{width,height}(), and that's enough to support 
non-xinerama multihead mode.  i suppose, for a xinerama-enabled setup, 
gdk_display_get_n_screens() will return 1, but 
gdk_screen_get_n_monitors() will return something > 1.  in the former 
case, simply placing a fullscreen window at (0,0) is sufficient, because 
each screen gets its own coordinate space.  in the latter case, i'd need 
to use gdk_screen_get_monitor_geometry() to figure out both the size of 
the physical monitor and the (x,y) coordinate that corresponds to the 
origin point of the monitor.  i'm tempted to also support the ability of 
having a single huge fullscreen window that encompasses all monitors.  
however, this needs to be an option, because it's possible to have 
differing monitor resolutions such that you end up with a 
non-rectangular display.  xfdesktop CVS already requires gtk 2.2 at 
minimum, so making use of the rest of the API shouldn't be a problem, 
and i really like the added level of abstraction you get out of it.

whew, that was interesting.  time for bed for now.

    -brian