On Wed, 2008-05-28 at 09:36 +0200, Peter Bauer wrote: > I can't get a survey of what GFVS is. GnomeVFS is deprecated, but the > documentation doesn't tell something about a replacement or an > alternative: http://library.gnome.org/devel/references
See the "Migrating to GIO" section near the bottom of the GIO docs http://library.gnome.org/devel/gio/unstable/ > So I assume GVFS is again some collection of libraries. I suggest GIO is > at least part of it. GIO (part of glib) is the interface applications will use instead of GnomeVFS and GVFS is a set of plug-ins that enhance gio (for example to provide more file systems / better volume monitoring). > As far as I could understand DeviceKit isn't a gnome specific approach > (which is of course not bad!). And the API documentation from DeviceKit > http://hal.freedesktop.org/docs/DeviceKit/ > is either far from being complete or DeviceKit is not yet complete. DeviceKit is a) not yet complete; b) the successor to HAL; c) written by the same team that does HAL; d) a simple mechanism to enumerate devices and do operations on them. So it's natural to replace the HAL dep in gvfs and Nautilus with a DeviceKit one. > Isn't easier to extend GIO API? See this: > http://library.gnome.org/devel/gio/unstable/GDrive.html > wouldn't it be nice to have a function like g_drive_set_name next to > g_drive_get_name? > > And also some functions like > g_drive_get_fs_status //!< check if filesystem was properly unmounted > g_drive_check_fs //!< perform filesystem check where applicable > g_drive_check_fs_on_next_boot //!< ... > g_drive_get_fsck_period //!< where applicable... > g_drive_set_fsck_period //!< where applicable... > g_drive_format_filesystem //!< don't change partition, just format it If we want to do this, these functions will have to be on GVolume rather than GDrive. But keep in mind that gio/gvfs handles much more than just block devices. For example fsck, format etc. makes little or no sense on sftp, gphoto2, obex-ftp etc. file systems. > Or should this functionality be part of another library? Maybe all this > should be discussed elsewhere. But wouldn't be nice for the nautilus > team? My plan is to provide a set of GObject based libraries (one library at the glib-level (no gtk deps) and one library at the gtk-level for dialogs and widgets) to do this for block devices.. most of this is already done; just need to factor the code out into libraries http://gitweb.freedesktop.org/?p=users/david/gnome-disk-utility.git;a=tree;h=cd9c348a5188c28adc0cd541e3dec9c3e0ddf493;hb=9380c678b44cad4f8b06e0c4dd45029db36177b9;f=src So.. we could abstract this in GIO just like we abstract bits of it including mounting/unmounting/ejecting (e.g. add API to GDrive, GVolume, GMount). But I'm just not sure it's worth it.. it would add a lot of complexity to API's that we can never change... and given that the only realistic consumer of this API is Nautilus it seems like a lot of extra work for no gain. The only situation where it *might* make sense to do this is if a gvfs filesystem driver can offer similar functionality; e.g. a way to format the media / change the fs label. If it turns out this is the case, we can always build the abstraction and (for block devices) just call into the g-d-u libraries I'm working on. David -- nautilus-list mailing list nautilus-list@gnome.org http://mail.gnome.org/mailman/listinfo/nautilus-list