Re: Removable media management
- From: David Zeuthen <david fubar dk>
- To: Peter Bauer <comicinker gmx de>
- Cc: nautilus-list gnome org
- Subject: Re: Removable media management
- Date: Wed, 28 May 2008 08:30:45 -0400
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
> 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
> 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:
> wouldn't it be nice to have a function like g_drive_set_name next to
> 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
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
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.
] [Thread Prev