KDE4 printing: results of IRC meeting

[Alex Merry]

On Thursday 13 Sep 2007, Alex Merry wrote:
>   If we don't mind having some API that will be redundant by 4.1,
>   and possibly resulting inconsistent print previews between apps,
>   we can have something like my earlier suggestion:
>
>   [QK]Printer printer;
>   KPrintPreview preview(&printer);
>   doPrint(printer);
>   preview.exec();

Question 1: how should we go about doing print preview in 4.0?

Options:
(a) nothing in the print dialog, only a Print Preview option in the file 
menu (using above KPrintPreview class, for example).  Easy, doesn't 
even require wrapping QPrinter.
(b) Option in the print dialog, hidden away in a tab.  Can do this by 
subclassing QPrintPreview and QPrinter and depending on Qt 4.3.2.  Can 
combine with (a).
(c) Option in the print dialog, either an extra button or a checkbox 
like in KDE 3.  Requires writing our own dialog, including getting 
printer lists from the relevant system.  Current code in KDE Print will 
only do this for unix systems (CUPS, lpr etc).

> Extensible print dialog:
>   We can either implement our own dialog or we can use
>   QPrintDialog.  The latter option is ONLY POSSIBLE IF WE
>   REQUIRE Qt 4.3.2 OR LATER!!!  TT are exporting the
>   method qt_printdialog_add_extension_tab() in 4.3.2.
>   This will be proper API in 4.4, but we can use this in the
>   meantime from a KPrintDialog class.

Question 2: Is it OK to require Qt 4.3.2 for KDE 4.0?  Apparently due 
out very shortly.  If not, we need to write our own dialog (as in (c) 
in question 1).

Question 3: Should we go for the route of subclassing QPrinter and 
implementing QAbstractPrintDialog, rather than simply subclassing 
QPrintDialog (and possibly QPrinter)?  KPrintDialog may then use 
QPrintDialog internally or not.  This allows for greatest freedom for 
later changes in the KDE 4 series (such as implementing our own dialog 
or print engines).  We can still deprecate KPrint* in 4.x if we choose, 
and just have them wrap QPrint* functionality.

Question 4: How important is leaving the option of arbitrary page 
selection open?  We can have a QList<int> pagesToPrint() method in 
KPrinter, which we could combine with our own KPrintDialog.  If we 
don't add this now, and require all programs to use it, adding it later 
would mean non-uniform support for arbitrary page selection across KDE 
programs.

Alex





-- 
KDE: http://www.kde.org
Ubuntu/Kubuntu: http://www.ubuntu.org http://www.kubuntu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070914/c1fda591/attachment.sig>