From kde-core-devel Thu Sep 13 14:40:28 2007 From: Thomas Zander Date: Thu, 13 Sep 2007 14:40:28 +0000 To: kde-core-devel Subject: Re: KDE4 printing: results of IRC meeting Message-Id: <200709131640.41870.Thomas.Zander () trolltech ! com> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118969448014017 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart6732206.5sA0SeZ34g" --nextPart6732206.5sA0SeZ34g Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 September 2007 01:30:00 Alex Merry wrote: > The two must-have features for 4.0 that Qt doesn't provide (yet) are > print preview and custom dialog options. Yesterday I realized that the actual problem was not really clearly defined= =2E I=20 bet that the majority of kde-core-devel readers just get a general "it don'= t=20 work" feeling; so let me go over that. INTRODUCTION KDEPrint is build around a basic assumption that QPrinter generates=20 postscript. You can see this by the fact that ghostscript is used heavily.= =20 =46or example to convert to pdf, but also to do 'filters'. With the introduction of Qt4 this situation changed considerably; QPrinter = is=20 now capable of generating not only postscript, but also PDF natively. And=20 since we want printing to work on Windows as well that adds the 'feature'=20 that QPrinter directly talks to the printer driver and the output of that=20 tends to be some sort of binary printer specific format. PROBLEM Due to the change of input most of the kdeprint will no longer be sufficien= t=20 for all cases where the application doesn't generate postscript. Which is= =20 KOffice and all apps on Windows. Things like print-preview can not work=20 anymore in those cases either and all filters stop working due to being=20 postscript based.[1] SOLUTION I thought things over a little longer after last nights irc discussion. Kee= p=20 in mind the normal implementation of code in an app, as I pasted here;=20 http://lists.kde.org/?l=3Dkde-core-devel&m=3D118951148406712&w=3D2 The long term solution IMO is that applications use the KDE kcm for printer= =20 configuration and job-queue tracking, but use a pure Qt solution for the=20 actual printing. This means that KPrinter and KPrintDialog will either not be present in KDE= 4.0=20 or will be present but be deprecated in KDE4.1 The biggest advantage of depending fully on Qt for this is basically man=20 power; we don't need the KDE capacity to maintain 3 platforms that all have= a=20 very different way of doing printing, which IMO is a biggy as we have seen= =20 kdeprint getting very little love over the last 2 years or more. Technically this makes it rather simple for KDE4.1. the KPrinter and=20 KPrintDialog classes are no longer needed and AFAIK this means that=20 kdelibs/kdeprint is no longer needed. All apps just Qt-only API for printin= g. =46or 4.0 I suggest to create a KPrintDialog which inherits from QPrintDial= og=20 and we add the ability to show application custom widgets there by providin= g a=20 method that apps use. (and deprecate KPrintDialog in 4.1 since Qt4.4 will=20 have public API for that) 1) we should note that ghostscript is capable of helping in several cases=20 here. But it is no panacea by a long shot. =2D-=20 Thomas Zander --nextPart6732206.5sA0SeZ34g Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG6UvpCojCW6H2z/QRAlcZAJ4w8UFwKoLDt3rKPhT7psfIQclsswCg5u0I ly/YOhOZ13pns1QqovZ5dvw= =cG5Y -----END PGP SIGNATURE----- --nextPart6732206.5sA0SeZ34g--