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
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
("\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
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
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:///.
Christian Neumair <chris@xxxxxxxxxxxx>
nautilus-list mailing list