DeviceKit-power release next Monday
pertusus at free.fr
Wed Oct 7 02:32:29 PDT 2009
On Tue, Oct 06, 2009 at 07:40:48PM -0400, David Zeuthen wrote:
> 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.
> 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.
> 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.
That being said, I think that a moving D-BUS API for DK* is not an issue
for the time being and maybe for a longer time, since it is not clear
to me how things are organized. Although I would not like a GIO/GTK+ based
API, an abstract API above DK* could be the way to go instead of using
directly DK, and there are certainly other possibilities. And until such
design issues are not solved, a stable API is not very appealing.
More information about the devkit-devel