KPrintDialog?

Harri Porten porten at froglogic.com
Wed Oct 24 08:04:29 BST 2007


Short update:

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

This is actually all that's needed to wrap the dialog:

KHTMLPrintDialog::KHTMLPrintDialog(QPrinter *printer, QWidget *parent)
     : KDialog(parent)
{
     QPrintDialog *qdlg = new QPrintDialog(printer, parent);

     // do not double margins
     qdlg->layout()->setContentsMargins(0, 0, 0, 0);

     QWidget *origButtons = qdlg->findChild<QWidget*>("buttonBox");
     if (origButtons)
 	origButtons->hide();

     setMainWidget(qdlg);
     setCaption(qdlg->windowTitle());
     setButtonText(KDialog::Ok, i18n("Print"));
}

and give it e.g. nice KDE icons on the buttons. But the communication with 
QPrinter is problematic. Even

void KHTMLPrintDialog::slotButtonClicked(int button)
{
     if (button == KDialog::Ok)
 	static_cast<QDialog*>(mainWidget())->accept();
     KDialog::slotButtonClicked(button);
}

does not suffice as setupPrint() is private and only called in 
QPrintDialog::exec(). And we do not want to execute it like that. So I see 
no way of solving this without duplicating the whole widget and its API. 
Which would basically mean re-importing quite some code that just had been 
thrown out for reasons I have not quite understood, yet.

Harri.




More information about the kde-core-devel mailing list