Projects/Summer of Code/2007/Projects/KDEPrint -- add support for LinuxPrinting's on-line drivers query

A note on this project's (and another's) name

The main thing to note is that LinuxPrinting is no more - long live OpenPrinting! Read the notes about the merger and be happy.

Student: Gavin Beatty

Introduction

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)

Abstract

The goals of this project are:

• Provide a simple, automated interface to downloading updated/new drivers from OpenPrinting.org by:
  • Updating the installed driver at the prompt of the user or if it is old/obsolete/not very featureful
  • Searching intelligently for the printer in the database
  • Retrieving the best suited driver package available for the printer based on features provided
  • Installing the driver package

Some key things to note about the intended implementation are that:

• It will use the KDE4 code base
• It will try to match as much as possible the current KDE "Get hot new stuff!" where suitable. Meaning that the simplicity of "Get hot new stuff!" will be the goal, but not at the expense of being informative and functional
• It will use the alien (if possible) to convert and install the driver if it's an rpm (most likely scenario)
• It will probably NOT use the actual KNewStuff api

Roadmap

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...

Printer/Driver query

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.

XML parsing

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.

Interface

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.)

Polish

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:

• Less popup dialogs, more "popup notifications" if that's the right word. I have the style used by amarok 1.4 for errors in mind.