On Sun, 2009-05-03 at 07:57 +0200, Frederic Peters wrote:
> I am all for DeviceKit-disks as an external dependency, but don't we
> want gnome-disk-utility as part of the desktop set ? It features many
> things, notifications, Nautilus extension, awesome replacement for
> gfloppy, and more, things that definitely have their place in the
> desktop. Just like Emmannuel I'd love to have it in the desktop suite.
>
> And being a whole part of the GNOME desktop was what I understood from
> David announce[1] (but then I could have read too much in this):
> > This will be the default volume monitor in GNOME 2.28
>
> David, would you formally propose gnome-disk-utility for inclusion in
> the GNOME Desktop Suite ?
Sure, that sounds sensible. The long term plan of this work is to have
- two libraries, libgdu and libgdu-gtk
- a set of applications / utilities
- deep integration with GNOME (e.g. Nautilus extensions, panel
items / applets, GVfs volume monitor)
for dealing with storage devices. The idea is that the bulk of the work
is in the libraries (including GTK+ widgets and dialogs) thus allowing
people to experiment and iterate over what kind of end-user experience
we want.
I'm not yet ready to commit to any kind of stable API (yet) but that
shouldn't be a problem as we can just update GVfs et. al. along and
AFAIK there's no guarantee of any API stability in Desktop, only in
Platform.
However, one thing is that the (D-Bus) API of the daemon being used,
DeviceKit-disks will remain API unstable for a bit longer (long term
plan is to provide a stable API) - probably until the GLib/D-Bus story
is sorted (see e.g. gtk-devel-list) and we have other backends (I want a
backend for unit tests and of course ideally FreeBSD, Solaris and others
could write backends too).
This "Device-disks is API unstable" might be a hard pill for some
distributors to swallow, e.g. they would need to rev DeviceKit-disks
whenever a new GNOME release is out. Which includes revving things using
DeviceKit-disks as well (it's not unlikely KDE and others will switch to
DeviceKit-disks at some point).
Also, the requirements for running DeviceKit-disks is also going to
remain bleeding edge - to do integration on the level we want (e.g. do
it right, for starters), we really need to depend on kernel and udev
features as we add them.
These shouldn't be problems for most distros, e.g. Fedora, OpenSUSE,
Ubuntu, Mandriva etc. all tend to ship bleeding edge stuff _anyway_. It
might be a problem for other OS'es (DeviceKit-disks is Linux only at the
moment), jhbuild users and infrequently release distros (such as the
enterprise releases or Debian). The only answer I have to this is that I
will ensure that things (like GVfs) will build with --disable-gdu and
then people can fall back to e.g. the HAL backend or whatever.
With the caveat that these things will not be problem (because, no, I
will not spend time making things work on ancient kernel or udev
releases) for inclusion in the Desktop release set, I'd be more than
happy to propose gnome-disk-utility.
(Btw, it's not like DeviceKit-disks is in any way special here - these
things apply to _many_ bits of an OS too (e.g. graphics, audio) - I'm
just trying to be upfront about these things in order to manage
expectations.)
> Finally, minor technical point: it requires libsexy (for SexyUrlLabel).
I can ship a local copy if this isn't in GTK+ by the 2.28 release (I
believe the plan is to get something like this into GTK+).
David
_______________________________________________
gnome-utils-list mailing list
gnome-utils-list@...
http://mail.gnome.org/mailman/listinfo/gnome-utils-list
signature.asc (196 bytes) 