KPrintDialog?

[Harri Porten]

On Tue, 23 Oct 2007, John Layt wrote:

> My main concern about lightly wrapping QPrintDialog with KPrintDialog in 4.0
> was the same as wrapping QPrinter with KPrinter:

Didn't it save its settings and stuff and was therefore absolutely worth 
it for the 3.x lifetime?

> we don't know for sure yet that we want to go down the inheritance route 
> in 4.1 (or even can), we may end up with composition or even our own 
> completely separate KPrintDialog again.  If it's doable without breaking 
> BC or having to create a KPrintDialog2 or having legacy api's hanging 
> around for years

We are developing KDE 4 for two years after Qt 4.0 came out. I don't think 
we have to think in terms of decades of code maintenance before version 5.

> (the neat freak obsessive in me would hate that) then 
> I'll be happy to fly with it.
>
> Some other points to bear in mind:
>
> * Will a thin wrapper even fix the original issue?  I'm assuming Harri meant
> the 'Save to File' filename edit box & file browser using Qt and not KIO.  In
> which case we would have to reimplement the layout to use a KUrlRequester
> instead of the current QLineEdit/QButton in the stacked widget.  If
> overriding .ui files is simple, and the api compatible or overrideable, then
> go for it.

Exchanging GUI components is easy but unfortunately QPrintDialog is not 
following the same principle of the Item View classes and has quite some 
printing system code in it. If that were in a non-GUI class things would 
be easier.

> * Will it still work OK across the 3 platforms, given that Qt simply hands off
> to the native Win/Mac dialog?  Should do, but we need to prove it, otherwise
> we lose half the reason for the port in the first place.

While I am a big fan of the cross-platform idea I would never accept it as 
enforcing the lowest common denominator. If a feature is not available on 
one of the supported platforms so be it. Still offer it to users on the 
other platforms.

What we have now is the most dumbed down solution I could think of. A 
primitive dialog on X11, only extensible by adding new tabs on X11 and 0% 
extensible on Mac or Windows. All the code of KDE apps that attempt to add 
new tabs will simply be ignored.

> * Is there even time before they tag libs tomorrow?

I have a KPrintDialog class that uses QPrintDialog (to avoid code 
duplication) internally for X11. On Windows and Mac one could embed it. In 
the mid term one could switch to make use of the native features and 
dialogs directly but I'm not going to get that done within the next 24h.

Big remaining problem: as QAbtractPrintDialog is an odd class (marked to 
be removed in Qt 5) that is both a view (QDialog) as well as data model 
(talking privately to the "friend" QPrinter). Wanting a KDialog for 
consistent look&feel we don't want to use it. But without it we'd have to 
duplicate the API and have not such a direct access to the QPrinter 
instance. Not elegant either until filled with life, i.e. new features 
lateron.

Just deriving KPrintDialog from QPrintDialog would be one safety measure 
guaranteeing us freedom for extensions for 4.0.1 already. But this would 
only get back a miniscule part of what we had in KDE previously. Probably 
won't get around opening the bridge to that within the next day and being 
flamed for compile errors I might cause. Alex took several days or weeks 
to port it away.

I know about the famous quote "The aim of this project is to get rid of 
the notion that QPrinter is not good enough for KDE."[1] and appreciate 
ambition but I wonder if our users (and us) will appreciate being held 
captive and waiting so long to have something as outstanding as 
printing.kde.org from KDE 3 back again.

Harri.

[1] http://lists.kde.org/?l=kde-core-devel&m=118918127627566&w=2