Ciao, > Sorry for my late answer. I wanted to think of your questions a bit and I also have very little time. No problem, I was busy too.
> So, here is a first iteration of what I think KDEPrint would > require from a platform like Solid. BTW, if there are already some > principial design documents for Solid, please be so kind and point me to > them. For now you should see solid's source code: http://websvn.kde.org/branches/work/kdehw/solid/devicemanager.h?rev=542227&view=markup http://websvn.kde.org/branches/work/kdehw/solid/device.h?rev=542224&view=markup > So: KDEPrint would require: > > a) a signal to which the kdeprint daemon can connect, and which would > inform about new printers connected to the system. The information > transfered through this signal would be of medium complexity: > - printer model > - means of connection > > b) a standard mechanism (perhaps XML based) by which Solid could inform > KDEPrint of capabilities and features that the printer advertises itself > (e.g.: are there special paper trays installed? Is the color cartridge > installed? etc.) > > c) a standard mechanism for communicating status: > - toner level > - paper missing > - paper jam > - etc (based on printer capabilities, communicated with mechanism at > point > b) - printer offline > - job printing completed and finished Solid can handle only the first request. Solid can send a signal when a device is connected or disconected and it can get those properties from hal: device, vendor, product, serial, description and commandset. Those properties are available on Printer capabilities. If you want more information you can subscribe the solid's mailing list. Bye, Davide Bettio. _______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
