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
structure:
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
(gdk_screen_get_n_monitors()).
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
GdkScreen.
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
see.
>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
footprint.
-brian
More information about the Xfce4-dev
mailing list