KPrintDialog?

[John Layt]

On Monday 22 October 2007, David Faure wrote:
> On Monday 22 October 2007, John Layt wrote:
> > but to implement one for 4.0 would mean we lock ourselves into
> > some possibly wrong and irreversible decisions on implementation.
>
> How so? The API of QPrintDialog is simply one constructor and calling
> exec(), why can't we have a KPrintDialog with the same very simple API?
> Everything else will be implementation details -- which can all be changed
> for 4.1.

Well, I'm in way over my head on most of this, so if it's doable in a clean 
way then I'm happy to go with it.

My main concern about lightly wrapping QPrintDialog with KPrintDialog in 4.0 
was the same as wrapping QPrinter with KPrinter: 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 (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.

* 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.

* Is there even time before they tag libs tomorrow?

So, hey, give it a crack, if it works then I'll be happy to port over to it.

Cheers!

John.

--

Send instant messages to your online friends http://au.messenger.yahoo.com