On Mon, 2006-02-13 at 10:25 +0100, Alexander Larsson wrote: > On Fri, 2006-02-10 at 22:43 +0100, Christian Neumair wrote: > > On Tue, 2006-02-07 at 11:38 +0100, Alexander Larsson wrote: > > > On Sun, 2006-02-05 at 14:11 +0100, Christian Neumair wrote: > > > > The attached patch is meant to allow the user to modify a volume from > > > > within its target directory. It's not very well-tested. For instance, > > > > I'm not sure whether not setting the volume in > > > > libnautilus-private/nautilus-directory-async.c:link_info_done if the > > > > volume_id is NULL causes some problems when unmounting a volume. > > > > > > The general approach of having the link-to-volume object set the status > > > of the destination is wrong. It means the destination will work > > > differently depending on if the link to it is shown. > > > > Here we go. This one adds a new volume monitor which only deals with the > > target URIs, and adds context menu entries to the file menu, the > > background and the location context menu, and also reorders the > > selection-related mount/unmount items to be above "Properties" for > > consistency reasons. It extremely improves my Nautilus experience and I > > really think it's worth to breaking a few freezes. > > I don't like this patch, it always keeps all mountpoints always open, > which might lead to problems with unmounts, and it totally changes what > nautilus_file_has_volume/drive() means (it used to mean "this file > represents a volume, but now its also used for normal folders). > > I also think we don't need anything as complicated as a separate > monitor, since all it does is proxy information from the vfs monitor. > The only thing you need is to map from folder uri to what drive/monitor > is mounted there, and this info is availible using > GnomeVFSVolumeMonitor. Ideally there would be an API for it, but you can > just get all the volumes and look for it manually. This is not really a > performance problem, because there are not typically many volumes/drives > active, the objects are all in-memory, and this check is done seldom > (i.e. not for every file when loading a folder). I hope you prefer this one. I have no clue why I'm experiencing refcount issues. I initially thought it'd be my fault but even when adding multiple gnome_vfs_volume_ref and gnome_vfs_drive_ref calls, I had crashers. The volume monitor getters seem to dup the internal lists and ref each drive/volume, so I think I got the refcount right. I also wonder whether strcmping the volume/drive and the file in question's URIs is OK instead of using helpers. Can we really expect GnomeVFS to provide valid URIs, taken that it just uses URIs stored in GConf? During my debugging sessions I also discovered that _gnome_vfs_volume_monitor_disconnect_all and _gnome_vfs_volume_monitor_unmount_all don't free the list returned from gnome_vfs_volume_monitor_get_mounted_volumes. -- Christian Neumair <chris gnome-de org>
Attachment:
signature.asc
Description: This is a digitally signed message part