Re: gio changes for GVolume and GDrive

[Alexander Larsson <alexl redhat com>]

On Tue, 2007-12-11 at 04:11 -0500, David Zeuthen wrote:
> Hi,
> 
> I've started working on writing a hal implementation for GVolumeMonitor
> and have some suggestions making the volume monitor API better. First of
> all it appears that the current GDrive and GVolume abstraction is more
> or less a 1:1 copy of what was in GnomeVFS. 
> 
> There's a couple of problems with this approach. The main problem is
> that GDrive doesn't really represent a drive. It represents a mountable
> volume; typically such as partitions on a hard drive or entries in the
> classic /etc/fstab file. This breaks down if you have media with
> multiple partitions or mixed optical discs.
> 
> So part of this patch renames GDrive to GMountableVolume. Then we
> reintroduce GDrive as a new interface that more precisely represents
> what most people associate with the word ''drive'': a collection of
> mountable volumes and the notion of media.

In general I like this approach, however, the names just don't work for
me. GMountableVolume is kinda weird (is it a volume too? then why isn't
it a GVolume?). Also, if we start from a more physical definition i'd
say that a partition on a disk is a volume, not abstract "mounted
partition" os entity.

So, Maybe a better set of names would be something like:
GDrive <-1-n-> GVolume <-1-1-> GMount

Other alternatives for GMount: GMountedVolume, GMounted, GMountPoint
Any other ideas?

> There's also a some new API in gunixmounts.c that I needed for both
> backends. Thoughts? Also, I'm wondering, with these additions, if we can
> do away with GUnixMountType altogether; it's pretty much an eyesore.

You want guess_icon to return a GIcon so we can do icon fallbacks. I
agree that we should drop the GUnixMountType in the visible API. Its
just not something you can trust further than guessing icons/names, and
thats now availible in the API (with your patch).