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.) Regards, -- BKS
