another DeviceKit backend for Solid

[Lukáš Tinkl]

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 at redhat.com>
Software Engineer