Hi, (I'm not sure it's a bug in xfconfd, but it's the only app behaving like that, and I'm out of idea to explain why. Also, please correct me if I say something wrong.) According to the XDG base dirs spec, the first directory listed in XDG_{CONFIG,DATA}_DIRS is the most important one. Thus, in Xubuntu, we prepend /etc/xdg/xubuntu to XDG_{CONFIG,DATA}_DIRS, to provide a default customized configuration (so that people who want the vanilla upstream config can still use /etc/xdg/xfce4). All programs take this change into account, except xfconfd. Our first attempt was to override XDG_*_DIRS in /usr/bin/startxfce4, but it proved to be wrong because xfconfd is probably spawned before, or on a different shell by dbus (/proc/$xfconfd_pid/environ showed default XDG_*_DIRS vars). So far, no bug here. Second attempt: drop a script in /etc/X11/Xsession.d, which is sourced before the script starting dbus-launch. Thus, any program spawned after by dbus on this session should be aware of our new XDG_*_DIRS values. Indeed, /proc/$xfconfd_pid/environ contains these new values. Unfortunately, xfconfd still doesn't care of them (it doesn't search for channels in /etc/xdg/xubuntu/xfce4/xfce-perchannel-xml, but only in /etc/xdg/xfce4/xfconf/xfce-perchannel-xml). Interestingly, if I delete /etc/xdg/xfce4/xfconf/xfce-perchannel-xml, xfconfd will correctly use /etc/xdg/xubuntu/xfce4/xfconf/xfce-perchannel-xml. So maybe xfconfd is taking xdg directories from libxfce4util (xfce_resource_lookup_all) in the wrong order...
Created attachment 2737 quick and ugly patch that works here Maybe the bug is in xfconf_backend_perchannel_xml_load_channel(), because it seems to parse config files as returned by xfce_resource_lookup_all(): first /etc/xdg/xubuntu, then /etc/xdg (so values from the first one are overwritten). I tried to reverse the list, so that the most important file (/etc/xdg/xubuntu) is parsed last, and xfconfd behaves as expected.
Hmm, yes, it's documented in the xfconf spec docs that files found "later" via the xdg dirs override values found in "earlier" files. If that indeed conflicts with how the xdg basedir spec intends usage, I'm fine with changing it. The only thing that has to stay as-is to avoid breaking things is that the file in the user's homedir must be merged last. In that case all you should have to do is a one-line patch after the xfce_resource_lookup_all() line, something like: filenames = g_list_reverse(filenames); I don't have time to test this, so please give it a try yourself.
Ok. The only problem is that 'filenames' is only a gchar**, not a glib list, so: xfconf-backend-perchannel-xml.c: In function 'xfconf_backend_perchannel_xml_load_channel': xfconf-backend-perchannel-xml.c:1654: warning: passing argument 1 of 'g_list_reverse' from incompatible pointer type /usr/include/glib-2.0/glib/glist.h:80: note: expected 'struct GList *' but argument is of type 'gchar **' xfconf-backend-perchannel-xml.c:1654: warning: assignment from incompatible pointer type And it segfaults at runtime. ;]
Ah, yeah. Was not paying attention. Regardless, the correct (and only) fix is to reverse the array.
Created attachment 2741 possible patch Here is a possible patch that reverses the array.
Created attachment 2742 another possible patch In the previous patch, the new gchar** is probably uneeded: with this version of the patch it's more like an in-place reverse. (I tested both and they work fine here anyway)
I guess there's really no reason to reverse it... why not just find the array length and walk through it backwards?
Created attachment 2743 smaller patch (tested here also, works for me) Agreed, the array isn't used anywhere else, so I guess it was not so useful.
Committed a simpler patch in rev 13e913b.
Sorry to comment on a closed bug. ;( I'm trying to get the latest Xfce building for RHEL/CentOS5. This patch in the 4.6 branch uses "g_strcmp0" which the glib2 in RHEL5 is too old to understand. ;( (version is glib2-2.12.3-4.el5_3.1) xfconf checks for "gobject-2.0 >= 2.12.0" which this meets. ;( Is there any way you could come up with an alternate way of doing this test so as to avoid the g_strcmp0 call?
Mmm, my bad, will fix this and release a new version.
Fixed in branch, you can take the patch from there. Will release a new version later.
Awesome. Thanks for the quick fix.