GNOME Bugzilla – Bug 136271
Need to handle .desktop files as symlinks.
Last modified: 2005-07-11 20:08:17 UTC
Change testfilechooser.c to use the gnome-vfs backend. Press Ctrl-L and enter either "smb://" or "smb://myserver". If servers/domains etc appears, try double-clicking on one. The filechooser sees this as if you had selected a file: instead of going into the server/domain to display the shares/servers, it closes. On a side note: there is no "Network" shortcut yet.
Provisionally reassigning it to libgnomeui. May require filesel changes.
This is because these files are not directories. They are desktop file links. The file selector should perhaps support following desktop file links?
This also causes a problem when filters are in use in the file selector, as the desktop files may not even show up. The desktop file type needs to be determined to decide if it links to a directory or not.
Alex, what's your suggestion? Should the VFS backend have a special case for those desktop files, and create fake folders out of them?
Federico: I think the fileselector should really handle desktop file links in general. We use them as a form of symbolic links in nautilus, not only in smb://
Yeah, we should handle them in general. What's the right way to do that these days? See if the mime-type of the file is application/x-desktop and use the gnome_desktop_item_*() functions on it? If so, we have a problem :) gnome-desktop depends on libgnomeui, and the file system backend lives in libgnomeui. So, we can't use gnome_desktop_*() from it.
Retitling for clarity.
*** Bug 165537 has been marked as a duplicate of this bug. ***
Using the new glib-level desktop parser might be better.
I'm working on this.
The following patch is a work in progress. It more or less works for smb:/// and for navigating into servers/workgroups. Authentication is a bit broken (the auth window comes up twice; hitting Cancel doesn't give me a "you don't have permissions" error, etc.). Also, it doesn't seem to work for local .desktop files that link to other places in my file system. For example, use this: [Desktop Entry] Name=THIS IS A LINK TO DOWNLOADS Type=Link URL=file:///home/federico/Downloads Could someone please give this patch a try? I'm also attaching the sucky-desktop-item.[ch] files that I need --- those are gnome-desktop-item from the gnome-desktop module, cut&pasted because libgnomeui can't have a circular dependency on gnome-desktop. We *can* replace these with GKeyFile in the future; for now I want to get this working.
Created attachment 48187 [details] [review] libgnomeui-filechooser-desktop-links.diff Patch to be applied to libgnomeui.
Created attachment 48188 [details] libgnomeui/file-chooser/sucky-desktop-item.h
Created attachment 48189 [details] libgnomeui/file-chooser/sucky-desktop-item.c
Created attachment 48256 [details] [review] Updated patch for libgnomeui This updated patch now understands .desktop links to local files. It can also produce the icons that are referenced in the .desktop files, rather than showing a generic "application/x-desktop" icon. Known problems: - Right now it assumes that .desktop files with "Type=Link" are links to folders. This works for SMB and iFolder; it obviously doesn't work for random .desktop files that may link to files (or for the .desktop files which Nautilus creates when you drag a URL to the desktop). - When visiting a SMB share that requires authentication, I get two auth windows. Haven't investigated why this happens. I also don't get a "wrong password" dialog if I type in random stuff; I don't know if this is the job of gnome-authentication-foo or of the file chooser itself. - I have only tested this with three (count 'em, 3) very simple .desktop files.
The "is a folder" issue is tricky. You don't in general want to do I/O on the target of the desktop file before its clicked, since this can (and often do) end up with you getting an authentication dialog. I don't think you get a "wrong password" dialog. Just an authentication failed error return. I'm not sure why you get multiple auth dialogs. Are you starting multiple i/o requests in parallel? Are you mixing sync and async calls?
Federico? poke?
I mix gnome_vfs_directory_async_*() with gnome_vfs_get_file_info(). This is probably why the auth dialog comes up twice... I haven't had time to trace it. I'll commit the patch as it is and take care of the auth dialogs later. The file chooser's structure in theory allows you to avoid stat()ing files until you really need the info; this is probably not being done correctly everywhere.
I've committed this to gnome-2-10 and HEAD. I'll open another bug for the auth issue.