DeviceKit-power release next Monday

[David Zeuthen]

On Wed, 2009-10-07 at 11:32 +0200, Patrice Dumas wrote:
> On Tue, Oct 06, 2009 at 07:40:48PM -0400, David Zeuthen wrote:
> > Hey,
> > 
> > For DKD, don't expect a stable API anytime soon. FWIW, I even doubt that
> > it's useful to make the API stable. It's kinda-sorta an API that is
> > useful only for the OS vendor to implement a desktop environment or an
> 
> What OS vendor are you talking about, and what 'desktop environment' are
> you talking about? I think that there are no such things at the DK*
> level. Indeed DKD is about doing stuff with disks, this shouldn't be 
> linked in any way with high level issues like how an installer or a desktop 
> is done. That doesn't mean that the interface should be D-BUS based, 
> but it shouldn't be desktop or vendor specific.

I wasn't talking about any OS vendor in particular. The point here is
that DeviceKit-disks is a distro-neutral interface where the obvious
users are things like GNOME Disk Utility, the GNOME desktop shell (e.g.
Nautilus) and in the future things like OS installers (which may or may
not be distro-neutral).

> > Applications (that are not disk utility, partitioning etc. apps) should
> > just be using the GIO API since it's simpler and do what they need
> 
> I am not very knowlegable about gnome, but it looks like very gnome centric
> and not at the same level as DK at all. It even seems that it requires 
> a specific daemon running.

GIO is engineered to provide the kind of API that regular desktop apps,
like a word processors, media players etc. are expected to use. Things
like Evince, OpenOffice, Rhythmbox, Banshee etc. comes to mind.

Anyway, part of "what API regular apps need" includes enumerating
storage devices. I was trying to say that it is a bug if such apps use
DeviceKit-disks (the same way some of these used to use HAL) instead of,
say, GIO. Or whatever equivalent the Q or E or whatever stack is
providing. That's all.

> > I think the same goes for DeviceKit-power: For the few bits where apps
> > need to care about power management (if any?), GLib and/or Gtk+ really
> > should provide abstract interfaces whose concrete implementation uses
> > DeviceKit-power on Linux and other free platforms. GLib and/or Gtk+
> > would also provide implementations on Win32/OS X/whatever that uses the
> > appropriate OS specific stuff.
> 
> I really can't see how a gtk+ interface would correspond with DKP. Maybe 
> GLib (to avoid reinventing low level functions), although it would be 
> better if it is more independent, but gtk+ doesn't make sense to me. It 
> is much too high level.

Some apps do need to deal with power management - for example, for long
running operations without user interaction (like copying a file or
burning a CD) needs to ensure that the system won't suspend. Again,
these apps shouldn't use DK-p - they should use an API provided by the
toolkit stack they are using.

    David