Re: How nautilus manage drive icons

[Christian Neumair <chris gnome-de org>]

Am Montag, den 08.05.2006, 22:26 +0200 schrieb Xavier Claessens:
> Le lundi 08 mai 2006 �0:44 +0200, Christian Neumair a �it :
> > Am Sonntag, den 07.05.2006, 14:52 +0200 schrieb Xavier Claessens:
> > > Here are some examples of buggy drive/volume management in nautilus:
> > > 
> > >  - Open nautilus to computer:/// and DnD the cdrom icon to gnome-panel.
> > > An icon appear (great !) but when clicking on it an error appear, it
> > > can't open nautilus to browse the cdrom. If we unmount the cdrom the
> > > icon on gnome-panel isn't refreshed. In fact it creates a launcher on
> > > the panel with no command to run when activated.
> > > 
> > >  - Do the same thing with the cdrom's icon on the desktop, the panel
> > > seems to accept the drop (mouse pointer as the "+" icon) but when I drop
> > > it nothing happens, no icon. Maybe better than a broken icon, but the
> > > problem is that for the user it should be the same if the icon come from
> > > computer:/// or from the desktop.
> > > 
> > >  - Drag a volume icon from computer:/// and drop it your home folder. An
> > > icon is added with the (readonly symbol). clicking on it opens the
> > > volume (great !!!), right click on it shows volumes options like unmount
> > > (great !!) but when I unmount the volume from computer:/// the icon on
> > > my home isn't updated, even if I refresh the folder in nautilus.
> > > 
> > >  - Do the same thing from the desktop and drop it to your home, nothin
> > > happens, but the mouse's pointer seems to say that you can move the icon
> > > to your home.
> > > 
> > >  - I can right-click->copy a volume in computer:/// but not in desktop.
> > > 
> > > To solve those bugs we should have a common way to manage volumes/drives
> > > icons in nautilus and in GNOME. I really don't know how to fix that but
> > > it have to be discussed, I think.
> > 
> > Thanks for bringing this up Xavier! Most of these issues were reported
> > multiple times, so it is a clear annoyance for our users.
> > 
> > It is important to realize that volumes and drives are present both as
> > GnomeVFSVolumes/GnomeVFSDrives in the GnomeVFSVolumeMonitor, and as
> > files in the VFS and in Nautilus. The file representations by the VFS
> > are in computer:///, and they are created on the fly. They are used by
> > Nautilus, and they map to a desktop icon file, and can be dragged to the
> > panel.
> > 
> > The representations created by Nautilus are in x-nautilus-desktop:///
> > (cf. libnautilus-private/nautilus-desktop-link.[ch]), and they don't
> > refer to file entities, but Nautilus knows that they refer to volumes
> > because the nautilus_file_set_volume API was used.
> > 
> > >From a user POV, the volumes and the file representations are identical,
> > while technically they are not, so we have to find a way for dealing
> > with their DND that is not bound to files.
> > 
> > Let me put together an idea, I'm not sure how feasible it is:
> > 
> > Nautilus offers a "gnome-vfs-volume-list" drag target if some of its
> > files that are dragged are volumes, the format is
> > 
> > volumeid1
> > source_uri1
> > ...
> > volumeidN
> > source_uriN
> > 
> > ("\n" would have to be escaped to "\\n" in the strings)
> > 
> > each of these refers to a volume that can be obtained using 
> > gnome_vfs_volume_monitor_get_drive_by_id, each of the (possibly empty)
> > source URIs may specify an URI, to allow the drop target to filter out
> > the respective item from the "text/uri-list" target when processing
> > non-volume drop items. Note that we can offer a similar drop target for
> > drives.
> > 
> > The panel would recognize this target, and create a special item is
> > associated with a particular drive or volume ID, and that represents the
> > volume and is kept in sync. Maybe this can also be integrated with the
> > disk mounter.
> > 
> > I'm not sure about dragging volumes and drives to file systems. We could
> > create special objects explicitly referring to a volume, but I don't
> > think this is really useful. Maybe we should operate on the dragged
> > volume's activation URI if it was dragged to a location other than
> > computer:/// or desktop:///.
> 
> I think file representation is more usable. As I understand nautilus
> generate .drive files on-the-fly to populate computer:///. Those files
> are simple text file that looks like .desktop and seems to be supported
> for most applications. gnome-panel accept .drive files and says it is a
> launcher of type "FSDevice". So it should be possible to make it work,
> just a matter of bug fixing in gnome-panel to make it start nautilus
> when clicking that kind of launcher. gnome-panel adds a .desktop file in
> ~/.gnome2/panel2.d/default/launchers for the drive launcher when I do
> DnD from computer:/// This file looks like that:
> 
> [Desktop Entry]
> Version=1.0
> Encoding=UTF-8
> Name=stoque
> Type=FSDevice
> Icon=gnome-dev-harddisk
> URL=file:///media/hdc1
> X-Gnome-Drive=4
> 
> So all information needed are there. good point ! I'll try to patch
> gnome-panel to make it work with that kind of desktop file. That isn't
> trivial because it need to connect some signals to know when the drive
> is (un)mounted and refresh the icon. But doable I think...
> 
> For volume icons from the desktop, is it possible to make it work like
> in computer:/// ? nautilus should generate on-the-fly same .drive files.
> Like that we are sure that at least icons from desktop and from
> computer:/// react the same way.

Passing around on-the-fly generated files (which would have to be put
into file:///tmp) isn't a good idea IMHO, because it requires sniffing
foreach passed-in URI. My proposal tried to address the fact that some
applications are interested in volumes or drives but not in their
corresponding files, since the actual volume/drive data can be queried
from the volume monitor.

> Last problem: what about dropping a volume icon in a folder ? For now it
> works. If I drop in my home directory the same icon that I did for the
> panel, I get this file in /home/zdra :

What do you mean by "it works"? It doesn't work!
The .desktop file just reflects the current state of the volume/drive,
but not modifications (unmounting, ejection) to it.x

> 
> -r--r--r--  1 zdra zdra    119 1970-01-01 01:00 stoque.drive
> 
> containing :
> 
> [Desktop Entry]
> Encoding=UTF-8
> Name=stoque
> Type=FSDevice
> Icon=gnome-dev-harddisk
> URL=file:///media/hdc1
> X-Gnome-Drive=4
> 
> So that's the same desktop file I have for gnome-panel. Just a little
> patch to make this file writable by the user ? And another patch to make
> nautilus refresh automatically desktop files displayed in a nautilus
> window, that's maybe not easy and I think most of the work can be shared
> with gnome-panel (which should also refresh this file like said before).



-- 
Christian Neumair <chris gnome-de org>