xfdesktop woes

Brian J. Tarricone bjt23 at cornell.edu
Sat May 29 21:55:44 CEST 2004

Olivier wrote:

>Xinerama is really something different. It has nothing to do with
>multihead (even if Gdk API tries to make you think it's releated)
i'm aware of this, but i was able to generalise my implementation enough 
so that it'll work with both xinerama and non-xinerama multihead without 
having to think of it in two different ways.  basically i have this 

XfceDesktop - main struct, holds all globally shared stuff.  also has an 
array of pointers to:
XfceDesktopScreen structs - represents one GdkScreen.  contains 
per-screen information, and has an array of pointers to:
XfceBackdrop structs - represents a backdrop image/color, and it knows 
where on the virtual root window to place itself, and how large it 
should be.

if you're curious about implementation details, please see the 2nd 
tarball i put on my webserver.  the relevant portions are 
src/xfdesktop.[ch] and xfce_backdrop_new() in src/backdop.c.  basically 
the flow goes like this:

xfce_desktop_new( ) {
    check number of GdkScreens (gdk_display_get_n_screens()).
    foreach GdkScreen {
        call xfce_desktop_screen_new()

xfce_desktop_screen_new() {
    create a fullscreen virtual root window
    check the number of monitors on this GdkScreen 
    foreach monitor {
        call xfce_backdrop_new()

xfce_backdrop_new() {
   figure out the monitor attributes (gdk_screen_get_monitor_geometry())

in the case of a single non-xinerama screen, it seems a bit overly 
complicated.  gdk_display_get_n_screens() returns one,  
gdk_screen_get_n_monitors() returns one, and 
gdk_screen_get_monitor_geometry() returns and x and y of zero and a 
width and height equal to the size of the GdkScreen.

for two non-xinerama heads, you end up with gdk_display_get_n_screens() 
returning two, and then gdk_screen_get_n_monitors() returns one for each 

for two xinerama heads, gdk_display_get_n_screens() returns one, and 
gdk_screen_get_n_monitors() returns two for the single GdkScreen.

you don't really see the benefits of this approach when you have a 
simple, one-monitor setup, but if you have multihead, the benefit is 
clear, as xfdesktop doesn't have to care if you're using xinerama or 
not.  i think the added memory requirement for the single-screen case is 
minimal and well worth it.

>So I just wanted to point that the current implementation doesn't work
>reliably anyway.
it appears to work fine for danny in non-xinerama mode, and, as i said, 
it doesn't have xinerama support.  Xnest _is_ buggy with regards to 
multiscreen, so it could be that that's the root of whatever problem you 

>I think (and I said so even before 4.0 was out) that it could be more
>interesting to make xfce-mcs-manager be able to read/save separate files
>for each screen of a given display. This way, if someone run 2 xfdesktop
>on each screen, the settings get properly saved /restored.
more "interesting" perhaps, but i think it is a _huge_ waste of 
resources to have separate instances loaded for each screen.  xfdesktop, 
in particular, shares the menu widget (and its associated data) between 
screens, simply calling gtk_menu_set_screen() when the user clicks on a 
different screen.  there are large memory savings by running a single 
instance of xfdesktop for all screens inside a logical display.

benedikt was talking about making xfce-mcs-manager multiscreen aware, 
but he was a bit vague on the details - mainly, he never said if you 
would have to run a separate instance of the mcs manager for each 
screen, or if it could intelligently store settings for different 
screens without the app itself having to do things like i'm doing (e.g., 
path_0, path_1, ...).  this method would probably require new APIs, and 
i would bet introduces a bit of code complexity.  i think the mcs 
manager is fine how it is - it should be a simple configuration manager, 
and if apps want to do things that need multiscreen-awareness, they 
should provide such awareness themselves.

personally, i'm against anything that requires the user to run a 
separate instance of apps to get them to run on more than one screen.  i 
think that's a big waste of memory, and i'm surprised that you'd 
advocate such a path for xfce, which prides itself on having a low 


More information about the Xfce4-dev mailing list