From kde-core-devel Sat Sep 08 19:29:08 2007 From: Alex Merry Date: Sat, 08 Sep 2007 19:29:08 +0000 To: kde-core-devel Subject: Future of KPrinter Message-Id: <200709082029.17181.huntedhacker () tiscali ! co ! uk> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118927963316320 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart66087154.65IcvhPBbF" --nextPart66087154.65IcvhPBbF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thomas Zander suggested we kill off KPrinter in favour of QPrinter=20 (http://lists.kde.org/?l=3Dkde-core-devel&m=3D118918127627566&w=3D2). Here's a list of the features provided by the KDE printing system that=20 the Qt printing system doesn't provide: * Customisable print dialogs - would require implementing our own=20 KPrintDialog * Straightforward printer options (try clicking "properties" for a=20 printer in the print dialog of the Qt assistant program, and doing the=20 same in kolourpaint), ie: integration with KDE print management system -=20 would require implementing our own KPrintDialog * Printing a list of pages (such as 1,4,6-8) or the current page - would=20 required extending QPrinter and implementing our own KPrintDialog, or=20 we could just tell people to get this info from KPrintDialog (it's only=20 needed by the application, not by the printing system) * Custom margins - would require extending QPrinter and implementing our=20 own backends (which might use a Qt builtin backend) * Pre-print filtering - would require extending QPrinter and=20 implementing our own backends (which might use a Qt builtin backend) * "Special" printers (like Send Fax via KFax) independent of eg: CUPS -=20 would require extending QPrinter and implementing our own backends=20 (which might use a Qt builtin backend when not printing to the special=20 printers) * Print preview - more complicated. We could probably provide a=20 KPrintPreview class that uses a QPrinter to print to a file and then=20 display that: QPrinter printer; KPrintPreview preview(printer); // configures the printer as needed // paint to the QPrinter as normal preview.show(); Note that the printer kcm could be kept (without the option=20 for "special" printers except via eg: CUPS) even if the whole of the=20 kde printing API was scrapped. Are custom margins really needed? So, the choices are: * scrap KPrint* and just use Qt's system, (but keeping the printers kcm) * scrap KPrinter and use QPrinter, but provide KPrintDialog as an=20 extensible printing dialog integrated with the KDE print management=20 system (and it can also delegate to QPrintDialog on Windows), and maybe=20 KPrintPreview as above - this is what Thomas suggested * provide KPrinter, a subclass of QPrinter, and potentially implement=20 our own backend(s), as well as KPrintDialog Personally, I'm being more and more convinced by Thomas' suggestion=20 (together with KPrintPreview). If we get programs to get a page list=20 from KPrintDialog rather than QPrinter, we should be able to implement=20 everything except for pre-print filtering and special printers. The=20 latter we could possibly even do using QPrinter::setPrintProgram() [on=20 X11 only], and the former seems quite specialist. I'd like a decision to be made on this ASAP, please, so I can start=20 working on something. Alex PS: Thomas said that he will talk to the printing trolls about the=20 missing features, but we wouldn't get them until 4.4 and we may not get=20 any of them, of course =2D-=20 KDE: http://www.kde.org Ubuntu/Kubuntu: http://www.ubuntu.org http://www.kubuntu.org --nextPart66087154.65IcvhPBbF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBG4vgEBRauKLutZ9ARAqhkAKCKw71Je7+sxxJpDq7rhd/1mJQCeACfcVv3 wHxRkkJhbISub9HpfyxGmT8= =L4Al -----END PGP SIGNATURE----- --nextPart66087154.65IcvhPBbF--