john.layt.net

I've been poking around in the Qt 4.4 printing code trying to get a better understanding on how it all hangs together, with on eye on how to extend it in KDE 4.1 to meet our requirements. What follows is more a late-night brain dump of a couple of ideas to remind me later what I'm thinking, or to enable others to do it if I don't. I'll flesh it out later in the wiki.
We lost a number of popular user features in the switch from KDEPrint to Qt Printing, such as 2-up, banners, scheduled printng, etc (just open the KDE3 print dialog and compare the available options to the KDE4/Qt4 version to see). While Qt 4.4 has an API to add extra tabs to QPrintDialog to provide the GUI for restoring these features (*nix only), many features will depend on setting advanced CUPS options (2-up, scheduled printing, etc), and I had been wondering how to get QPrinter to do that when there is no documented API to do so.
However, if I'm reading the code right, the Qt CUPS/PDF QPrintEngine sub-class extends the base QPrintEngine::PrintEnginePropertyKey enum to include PPK_CupsOptions, a list of the Cups Options for the PPD Properties set in the Print Dialog. These options then get passed to CUPS at print time. We may be able to use the QPrintEngine API to add any extra CUPS options we want after the Print Dialog closes, but I need to test to confirm. I can definitely use this in the FilePrinter utility to read the PPD Properties so they actually get respected, a major failing in FilePrinter at the moment.
If this does work, it also provides a way that we could re-introduce our own KPrintDialog again if we need to, while still using QPrinter to talk to CUPS (although the cross-platform issue would then then crop up again if we didn't inherit from QAbstractPrintDialog?).
Talking of FilePrinter, while I plan to re-implement it in 4.1 as part of kdelibs to talk directly to CUPS and thus solve many of its shortcomings, a more elegant method might be to do so as a QPrintEngine. QPrinter embeds a QPrintEngine which abstracts and implements the actual painting/printing routines for the current platform, so there's engines for Mac, Win, CUPS/PDF, and lpr/PS. It also allows you to implement your own print engines, so in theory that's a way to support say RLPR or LPRng if there were demand. It wouldn't take much re-working to fit FilePrinter to this model, no painting code would actually be needed, just a new Print Engine Property for PPK_PrintSourceFile, and some code to pass the file to CUPS or lp/lpr. Now, if only the Trolls could implement this themselves, they could use their existing internal CUPS/lpr classes or code, provide a more seamless API, and save me the effort :-)
I'd like to make FilePrinter cross platform, but while I believe Mac would be easy, the only solution I know so far for Windows would be forcing the users to install Ghostscript and using that to convert the PDF or PS files to the Windows printing format. Lower priority for now.
So, once I have a more permanent roof over my head and get my printer back, I'm going to make a start on porting as many of the old KPrintDialog features over to QPrinter/QPrintDialog as possible. With regard to KDEPrint itself and the Admin features, I see no point in trying to get a version done for 4.0. Instead we should move straight on to stripping down and re-factoring KDEPrint into a more targetted set of admin tools. The famous kprinter command line utility and kdeprintfax would get separated off to be based on QPrinter/QPrintDialog. The remaining backend code would get cleaned up, namespaced, and concentrated on supporting CUPS and lpr admin, with the KCM, Add Printer Wizard, and Job Viewer being the main targets.
Yawn! To bed...