GNOME Bugzilla – Bug 504323
Folder as .desktop visible in filechooser but cannot be used
Last modified: 2015-07-04 05:38:18 UTC
I use .desktop files as "shortcuts" on the desktop to at-the-moment important folders. This works with nautilus, but it doesn't work very well with gtk+ as the file chooser dialog can't handle the .desktop files. The .desktop files are visible (as folders) in the file chooser, but cannot be used. When double clicked they open a (non-existing) folder (named after the .desktop "Name" property), while they should open the folder in the "URL" property. 1. create a folder ~/foo 2. create a text file ~/Desktop/foo.desktop 3. paste this inside the text file: [Desktop Entry] Version=1.0 Encoding=UTF-8 Name=foo_desktop Comment=Open "file:///home/markus/foo" Icon=gnome-fs-directory URL=file:///home/markus/foo Type=Link 4. replace /home/markus with your $HOME 5. Open gedit (behavior also verified with firefox 3) and enter some text in a new file 6. Choose "Save as..." and browse to ~/Desktop/foo Expected behavior: the content of folder ~/foo is listed and when Save is hit the file is saved in that forlder. Actual behavior: the content of a non-existing folder ~/Desktop/foo is listed (well.. it's empty.. so..).. And the saving fails as the folder doesn't exist.
The text in the desktop file I pasted was wrong, the name should say just "foo" to match the rest of the explanation.. however, this has nothing to do with the bug behavior.
if this works in nautilus, i guess we should support it in the file chooser too.
This used to work fine before the async changes.
Hmm. Cannot reproduce the described behaviour: When running with "gnome-vfs" backend, the attached program works as expected: A "foo_desktop" folder appears. Choosing it enters the desktop folder, and choosing a file there gives the proper filename and URI. When running with "unix" backend the temporary desktop file is listed and choosing its gives its proper filename and URI. Tested with Ubuntu 7.10 (gtk: 2.12.0, libgnomeui: 2.20.1.1), jbhuild for gnome-2.22 (gtk: 2.12.4, libgnomeui: 2.21.0) and gtk trunk. Same effect with gedit.
Created attachment 101273 [details] Test desktop-file links
Yeah, it works as expected with the gnome-vfs backend, and doesn't work (as exected) with the unix backend. It does not work, however, with Carlos' gvfs backend - that probably needs fixing.
*** Bug 613630 has been marked as a duplicate of this bug. ***
*************I THINK THIS IS IMPORTANT: Slax Linux distro, that uses KDE (based on Qt) (instead of GNOME & GTK+), has the same problem!!********************* I think this problem is basic and important & should be fixed. Otherwise it's not possible for (old, ...) people that only (know to) use the computer to send emails (and very few other things) to send attached their photos, ... in their email messages (they don't know how to find their folder from / -file system root-; they only know to use the launcher or shortcut someone else created for them). More info in bug 613630. Please, don't force them to use Windows .... I hope this will be solved. Thanks.
Confirmed here in GTK+ 2.20
There is a workaround: Open a terminal and create a symbolic link: ln -s /the/destination/folder ~/Desktop/link ( Taken from http://www.slax.org/forum.php?action=view&parentID=59037 ) ( FOR KDE based distros: in the file system navigator window, to see the just created symlink, it may be necessary to click on the refresh button. )
I've learned that Firefox for Linux uses GTK dialogs, no matter if the Linux distro uses KDE or GNOME. I thought that KDE based distros didn't have GTK packages but I've seen that they have some. So many Linux users should be waiting for this to be solved ... I hope this will soon be fixed. Thanks for your work & good luck.
I don't think we will support Type=Link desktop files - they are a historical curiosity at best, at this point.