Re: Associating a volume icon with its contents

[Alexander Larsson <alexl redhat com>]

On Tue, 2005-10-18 at 16:51 +0200, Christian Neumair wrote:
> People demand unmount caps from within the target volume toplevel
> directory, for instance for their server links or for their mounts. Do
> you think we should call nautilus_file_set_volume/drive on the target
> file in link_info_done from
> libnautilus-private/nautilus-directory-async.c, and reference the target
> file, or would you prefer a
> nautilus_directory_[gs]et_enclosing_volume/drive API?

Associate each file with a volume drive seems a weird thing to do wrt
the abstractions (has_volume means this object represents a volume), and
unnecessary work for most cases since this info is only needed in very
few cases.

> I'd go with the latter, since this allows us to distinguish between the
> volume representation and its contents.
> 
> We could set_(enclosing_)volume upon changes in a to be written volume
> monitor.

gnome_vfs_volume_monitor_get_volume_for_path() allows you to get a drive
for local paths. I guess you could just compare the current uri with the
list of connected volumes to detect that case.

However, are we really sure this is a good idea? It'll add yet another
way to do the same thing, filling up the menus with stuff, and I'm not
sure its such a natural place for it that people will find it easier
than the other ways. Or am I wrong?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an old-fashioned Catholic assassin with nothing left to lose. She's a 
mistrustful Bolivian nun who don't take no shit from nobody. They fight crime!