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
