Dne neděle 9. srpna 2009 00:57:34 Benjamin K. Stuhl napsal(a):
On Saturday 08 August 2009 16:06:05 Kevin Kofler wrote:
> Benjamin K. Stuhl wrote:
> > I committed another, alternative, DeviceKit-based Solid backend to
> > KDE's Subversion repository yesterday, in
> > branches/work/alternative-solid- devicekit. It grew out of some
> > experiments I was doing with writing a Qt-ish libudev wrapper (you can
> > see the API in solid/backends/udevqt.h). Since it got large enough to
> > perhaps be useful to other people, and also to convince me that the
> > general approach would work, I imported it into Subversion from my
> > GitHub repository. The major difference from Pino and Lukas's
> > work/solid-devicekit branch is that I also use libudev for enumeration,
> > as well as DeviceKit-*;
>
> Great! I told ltinkl this is necessary, he wasn't very thrilled by the
> idea.
I can appreciate his lack of enthusiasm since it adds some complexity to
the code, but there's no way to get things like camera information from
DeviceKit- * -- e.g. AFAICT gphoto's plan is that they will just dump a
.rules file into udev that attaches a GPHOTO_DRIVER property to the
detected cameras.
> > I have also made an effort to try to minimize the amount of boilerplate
> > code each Interface needs (c.f.
> > solid/backends/devicekit/dkdevice.cpp:dbusDeviceCall() and
> > solid/backends/devicekit/dkinterface.h). Please take a look and comment
> > or help out, especially if you know DeviceKit or libudev.
>
> In what state is it in? Is it something we could put into Rawhide,
> keeping in mind that the Fedora 12 release is less than 3 months from
> now? Or is it still incomplete and/or buggy?
>
> (We decided that the original work/solid-devicekit branch is not suitable
> because it's missing features the HAL backend has. With libudev, we
> should be able to provide those features.)
I would not say it's ready for Rawhide, especially since it doesn't have
all the Solid::Ifaces implemented yet. But even once the backend is
"finished" (and even it the code was bug-free), it's going to have some
regressions against HAL, simply because upstream projects like gphoto and
libgpod haven't yet released versions that store their eumeration data in
udev. Maybe by Fedora 13 those versions will be out and KDE can switch to
DeviceKit, but in the meantime there would be a lot of complaints of "why
did KDE suddenly stop detecting my camera?".
To be honest, libudev/DeviceKit-* currently lacks substantial features in
comparison with HAL. Maybe in the future there will be a DeviceKit-* for
every device imaginable, but in the meantime I feel like I'm having to
steal substantial amounts of ideas from HAL's addons to get the features we
need. (E.g. I'm currently writing a class that uses the sg or bsg device
associated with your cdrom drive to listen for eject button presses -- in
HAL, this is done by hal-addon-storage, but DeviceKit-disks doesn't provide
it.)
Those were exactly my objections against shipping a DK Solid backend; simply
because DK as it is now doesn't provide all the information HAL does. Users
would be "surprised" to see a loss/breakage of functionality, eg. cameras,
CD/DVD burning and perhaps a lot more.
I feel it will take a long time until DK matures enough to be generally
usable; these days it's only used by a few Gnome-only apps. HAL has a long
history and lot of work behind it which is not going away anytime soon in my
opinion.
--
Lukáš Tinkl <ltinkl(a)redhat.com>
Software Engineer