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). _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list