Red Hat Bugzilla – Bug 457740
xfce does not respect xdg user directory paths
Last modified: 2009-01-24 22:48:01 EST
Description of problem:
Since I'm unsure what component of xfce includes the user directory paths, I filed this bug in xfdesktop.
XFCE ignores directory paths set in $HOME/.config/user-dirs.dirs
In other words it does not consider the variables XDG_DESKTOP_DIR, XDG_DOWNLOAD_DIR, XDG_TEMPLATES_DIR, XDG_PUBLICSHARE_DIR, XDG_DOCUMENTS_DIR, XDG_MUSIC_DIR, XDG_PICTURES_DIR, XDG_VIDEOS_DIR
Exporting those variables does not help either.
I think most of them are useless for xfce but at least the variables XDG_DESKTOP_DIR and XDG_DOCUMENTS_DIR should be considered by the desktop environment, because it currently creates new directories for them.
It looks like the paths are currently hardcoded (ugh).
Version-Release number of selected component (if applicable):
See this thread from while back:
In short, it's probibly going to be in 4.6, but there are no plans to backport it to the current stable release.
Due to that, I am inclined to close this for now... unless you can think of anything further we can do?
I've been searching through the GTK+ and Xfce APIs and I modified xfdesktop, Thunar and xfce4-places-plugin to force them to respect the standard.
I'm sending you the patches, so you'll decide what to do. They just work to me.
Anyway since this was the first time I used those APIs you might want to double check them first.
These are the changes I made:
- xfdesktop now shows the files in the xdg user desktop;
- Thunar now uses xdg user directories for the desktop and templates; when files are sent to the desktop it links them from the right folder; also the "Go" menu now includes all the xdg user directories (of course the menu entries are still untranslated);
- xfce4-places-plugin now sends to the right desktop folder.
Well I hope that's useful
Created attachment 313481 [details]
patch for thunar
Created attachment 313482 [details]
patch for xfdesktop
Created attachment 313484 [details]
patch for xfce4-places-plugin
These are the patches.
Hmmm Thunar and xfdesktop work fine but the xfce4-places-plugin seems to crash after a while... I have to find out why.
updating patches... this time they are much more stable. even the panel plugin shouldn't crash anymore.
Created attachment 313775 [details]
updated patch for thunar
Created attachment 313776 [details]
updated patch for xfdesktop
Created attachment 313777 [details]
updated patch for xfce4-places-plugin
Excellent. Thanks for the patches.
Also, thanks for posting them upstream!
I will look and see if we can add them into the fedora packages in the mean time.
The only problem with the patch is that it requires glib2 >= 2.14 while plain xfce requires glib2 >= 2.6.0.
But this shouldn't be a problem for Fedora 9 since it ships with version 2.16.5.
Applied patch from comment #11 in xfce4-places-plugin-1.1.0-2.fc10.
Kevin, I really like the idea, so can I do ahead and check the patches for xfdesktop and Thunar in? I did some changes to xfdesktop yesterday but did not yet build them, so we can apply all fixes in one update.
Yeah, I have been looking at the patches and I like the idea too...
I'm fine with you going ahead and applying them to xfdesktop and Thunar.
Hopefully Andrea's work will be upstreamed in 4.6. ;)
Thanks again for the patches!
Applied in xfdesktop-4.4.2-5 on rawhide:
* Wed Aug 27 2008 Christoph Wickert <fedora christoph-wickert de> - 4.4.2-5
- Use Fedora icon for desktop menu plugin (#445986)
- Respect xdg user directory paths (#457740)
- Fix menu icons
- Fix CRITICAL register message on startup
- Fix for x86_64
- Simplify g_list_free code
Quite a lot of changes, so we should think about shipping this as an update for F-9 later.
Yeah, it needs time in rawhide to make sure we aren't missing anything.
I suspected there was something wrong...
Thunar was getting slower and slower so I took a look at the patch again.
I found and fixed the memory leaks I accidentally added.
Also I fixed a little mistake in xfdesktop and changed the variable names to comply the xfce source syntax.
Sorry for the mess, now the patches should be fine.
Created attachment 315407 [details]
thunar patch update 2
Created attachment 315408 [details]
xfdesktop patch update 2
Created attachment 315409 [details]
xfce4-places-plugin patch update 2
oh I forgot to say that because of the same errors, when thunar launched applications and those exited, it kept them in memory in 'defunct' state.
That's fixed too.
(In reply to comment #18)
> I suspected there was something wrong...
> Thunar was getting slower and slower so I took a look at the patch again.
> I found and fixed the memory leaks I accidentally added.
No problem, I had not yet build the new thunar package. I want to apply some other changes (see bug # 450784) that first need to be discussed in the Xfce SIG meeting on Thursday, so I'm not going to build Thunar before Wednesday. The other patches are applied in xfdesktop-4.4.2-6.fc10 and xfce4-places-plugin-1.1.0-3.fc10.
hello there :)
I'm going on with the work on these patches and I sent newer ones against 4.5.0 alpha to http://bugzilla.xfce.org/show_bug.cgi?id=4365
It shouldn't be hard to backport them.
Do you think it's worth backporting?
We already have the patches from the 29th in I think, except for Thunar.
(which we should push out soon).
Thunar 0.9.80 (the svn version) just contains many bugfixes on 0.9.0, so maybe it's better to update the version.
Anyway, in case you don't want to update, the patch for thunar doesnt really need a backport.
Just before building, still in the %build section, remember to run this:
exo-csource --name=thunar_window_ui thunar-window-ui.xml > thunar-window-ui.h
and you're done. The latest version of the patch is available at http://bugzilla.xfce.org/show_bug.cgi?id=4365
Another thing, maybe a bit offtopic here.
Still in case you aren't going to update, please have a look at this bug report:
It contains a very important patch for a bug in 0.9.0 that gets even worse with the changes I made.
(In reply to comment #26)
> pushd thunar
> exo-csource --name=thunar_window_ui thunar-window-ui.xml > thunar-window-ui.h
Is this also necessary when applying the patch from comment # 19 to Thunar-0.9.3? I guess it won't hurt, so I did.
> It contains a very important patch for a bug in 0.9.0 that gets even worse with
> the changes I made.
Applied. I wonder why this has not been fixed upstream.
Are there any further issues here? Or shall we close this now?
I'm going to go ahead and close this now... feel free to reopen or file a new bug if you spot any issues.