Re: gnome-disk-utility volume monitor



On Mon, 02 Mar 2009 09:52:07 -0500
David Zeuthen <david fubar dk> wrote:

> On Mon, 2009-03-02 at 15:42 +0100, Jannis Pohlmann wrote:
> > Hey,
> > 
> > On Mon, 02 Mar 2009 00:27:58 -0500
> > David Zeuthen <david fubar dk> wrote:
> > 
> > > Hey,
> > > 
> > > Here we go with the new native volume monitor to replace the HAL
> > > volume monitor. This volume monitor uses the gnome-disk-utility
> > > library (which is also used in the Palimpsest Disk Utility) which
> > > in turn uses DeviceKit-disks. Which in turn is the replacement
> > > for HAL.
> > 
> > we're about to adopt GIO/GVfs in Xfce and I'm a little concerned
> > about GNOME dependencies in GVfs. AFAIR, the HAL monitor already
> > depends on gnome-mount which means that in Xfce we'd have to write
> > our own HAL monitor just to replace gnome-mount with exo-mount.
> > With a dependency on gnome-disk-utility our situation doesn't get
> > any better, even if it's optional (a lot of distributions will
> > probably make it a hard dependency anyway).
> > 
> > So, I wonder ... wouldn't it make more sense to write a monitor
> > solely based on DeviceKit-disks to keep things desktop agnostic? 
> 
> Surely you can do that but note that the DeviceKit-disks D-Bus API is
> unstable and will be for some time. FWIW, it's not something I'm
> interested in doing; there's a bunch of client-side business logic in
> libgdu that doesn't make sense to have in the DeviceKit-disks daemon.
> And it doesn't make sense to have two copies (one in GVfs and one in
> gnome-disk-utility). So that's why I decided to have a base GObject
> based library with this stuff.

What about moving the relevant parts of libgdu into the GVfs monitor and
then making gnome-disk-utility use GIO/GVfs to detect disks? I don't
know how gnome-disk-utility is implemented but I wonder about the
direction of the dependency. IMHO it sounds more reasonable to make a
disk utility application depend on a VFS layer instead of making a VFS
layer depend on a part of a disk utility application.

But, yeah, I don't know about the code, so you probably have reasons to
do it this way.

> FWIW, the major deps for libgdu.so are currently something like this
> 
>  - libdbus-glib
>  - libpolkit-dbus
>  - libgnome-keyring
>  - libgio
> 
> I expect libdbus-glib to be replaced by libeggdbus-1 (and down the
> road libeggdbus might land in the GLib tarball under a different
> name) and I also expect there will be a gconf dependency or some
> other configuration system (which some day may be something GSettings
> which would also be in the GLib tarball). And polkit-dbus will be
> replaced by libpolkit-gobject-1 when porting to PolicyKit 1.0.

I've read about moving something like dbus-glib into GLib. That's fine.
What about polkit-gnome? GConf IMHO is a pure GNOME dependency since it
is not used by other desktops like Xfce or LXDE.

> I don't think any of these dependencies are GNOMEy at all; maybe
> gnome-keyring but that is already used in gvfs in other places.

Yeah, that's one of the other GNOME dependencies in GVfs I'm not really
happy with. GIO being part of GLib means that it's the only *real* VFS
choice for any GLib/GTK+ application. That being said, one of the goals
of GVfs should be to be truely desktop agnostic IMHO. And a lot of
desktops don't use gnome-keyring at all.

  - Jannis

Attachment: signature.asc
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]