Student: Gavin Beatty
Good printing support is a basic requirement of Joe Public. Not all realised immediately that Gmail Paper was questionable! In order to print, the community must provide for the bajillions of printers that exist. KDE should, nay must, be at the forefront of making the use of such a fundamental technology as printing, a pain-free experience.
However, as always with technology, the support end is rarely painless. Printer manufacturers do not always provide for *nix customers and this lack of support is often made up by the FLOSS community. So wherever a quick hack at printing "Hello World!" exists, the OpenPrinting database will be there to host it in a standard and informative way! Fortunately for us all, the database is not just home for a quick hack. With a vibrant community and support from many major manufacturers, OpenPrinting fills the gap in support for most. Where it is lacking, they are always improving.
(OpenPrinting provide much more than just the database and I implore anyone interested in printing to visit their website)
The goals of this project are:
Some key things to note about the intended implementation are that:
Finish exams! They are finished on June 10. This is very late in the year and does eat into SoC time but I will be able to work regardless. This was somewhat unforseen...
Querying the database should be very easy. A simple use of KIOSlaves (asynchronous download) to get the XML for the printers (using this query most likely. Perhaps further refined if ~800KB of XML is too large for example). A second query of type=drivers will then be necessary to find the details of the RPMs etc.
Small issues like caching can be tweaked easily.
Probably using a SAX2 style reader from the QtXml module (QXmlStreamReader seems the most suitable as it is a Stream reader). SAX2 is preferred over DOM style as we don't need a tree structure of the entire XML in memory - we only need to store info for a small subset of the tags in the XML, .i.e., the ones that likely/do match the user's printer.
The interface will be somewhat like KNS1 (I have not seen screenshots of KNS2 yet). The only design choice that is somewhat fundamental is whether to implement it as a Wizard or an Application. A Wizard seems the most logical.
It will NOT in all likelihood be a wizard integrated into the existing "Set up your printer" wizard. I believe there to be a use case for the functionality outside of initial setup. (Integration would be easy regardless.)
There will likely be some amount of spit-shine work needed to make the interface more KDE4 like. This being off the top of my head: