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