Navigation
User login
Syndicate
Print Preview
One difference with the change in printing system to use Qt is that Print Preview is no longer available as an option from the Print Dialog itself (we used to have a little tick-box to say Print Preview). Instead apps need to add an option for Print Preview to the File menu. There are actually good usability and technical resons for Qt not hving this option available, but I just want to address the practical consequence of this: most apps no longer offer their users a way of doing a Print Preview. Only Okular, KolourPaint, Kig, and KOrganizer have added the required Print Preview option to their File Menu (KOffice too, but they use QPrintPreview instead of KPrintPreview).
So this is a call to all apps that do printing to decide if you need to add Print Preview. Some apps it may not make sense, but if your app does any print rendering or painting that results in the printed output differing form the screen output then you should add Print Preview support.
It's real easy and shouldn't take 10 minutes to do, just add the Standard Action:
m_printPreview = KStandardAction::printPreview( this, SLOT( filePrintPreview() ), actionCollection );
then add your slot:
void KMyApp::filePrintPreview() {
QPrinter printer;
KPrintPreview preview(&printer, this);
doPrint(printer); // Your existing print rendering code
preview.exec();
}
Longer term, we will probably look to switch to the very nice QPrintPreview as KOffice has, but we won't for now as selecting Print from QPrintPreview produces a Print Dialog without the KDE enhancements. Once the enhancements have been upstreamed then it will make sense to switch. Or maybe by then we'll have the OpenPrinting dialog ready which has an embedded dynamic print preview.
- odysseus's blog
- 10489 reads
Comments
Why not reviving the KDE Print System?
I my opinion there are good reasons to have the print preview in the print dialog. It is the right place to check whether all the print settings are correctly set.
As Qt will not provide this, why not reviving the KDE Print System to provide useful printing again?
The big problem is the
The big problem is the Print Preview cannot show the effect of some of the print settings that are done in the print server (CUPS) or the printer, such as n-up. This is confusing to the user, why do some settings appear in the preview when others don't? Which do and don't? It's just a bad experience. To get around this would require CUPS to provide an API to generate Print Previews, it's something that needs fixing further down the stack. But that would not be a cross-platform solution, and nor would Qt implementing all the features themselves.
But I'm not saying Qt won't do this, I could well add a 'Preview' button in the dialog and they might well accept it, but this will just launch QPrintPreview and probbaly ignore most of the settings from the Print Dialog. It could be better to expand QPrintPreview to support the options that are not CUPS dependent like page ranges.
Long term, the OpenPrinting dialog looks promising, as it provides an interactive preview built into the Print Dialog, but it requires a major re-architecting of how apps talk to the print dialog to acheive that.
As for reviving KDEPrint, well you obviously don't realise the enormity of the problem, if we had the manpower and expertise we would never have let it die in the first place...
whats the difference?
I'm not sure I understand the difference between the KPrintPreview and the QPrintPreview. The API docs are less than helpful, and I'm not sure I follow the reasoning in your blog; there is no difference between the print dialog in Qt or KDE. Its the same one!
Can you extend the API docs maybe?
No difference other than
No difference other than the extra tabs we add in KdePrint::createPrintDialog() that add the CUPS options like n-up, banner pages, job options, etc, and the new hacks in 4.4 for odd/even pages and server-side page selection via CUPS. Where-as in QPrintPreview if you click on the 'Print' button you get the 'pure' Qt dialog without the tabs and extra options. Try File/Print directly in KWord versus File/Print Preview then Print to see.
KPrintPreview is ugly, it just silently prints to PDF and then calls the KPart, so is very limited in that respect.
I plan to submit a merge request in January to add the advanced page range stuff into Qt 4.7, and in Feb merge the CUPS options and file printing, so hopefully in KDE 4.5 the issue will be moot and we can migrate to QPrintPreview. See http://qt.gitorious.org/~odysseus/qt/odysseus-clone/commits/advanced-page-selection. But each app will still need to add the print preview slot as QPrintDialog doesn't have a 'Preview' button (well not yet anyway :-) ) so it's not a lost effort if done in the 4.4 timeframe, it just makes it easer to find where to do the migration.
Thats not really a good reason
The 'extra features' you talk about are purely GUI options for them, no data is lost if you end up in a print dialog without them, right?
If thats the case, then the balance between losing all the QPrintPreview features vs losing the ability to set n-up etc stuff is just not in favour of your argument to use KPrintPreview.
If a user wants these rarely used extra features he can use the KDE print dialog using the print directly (apparently new in KDE4.4, as I don't see any difference in 4.3).
Bottom line is still that the KPrintPreview should be deprecated ASAP and the right solution is indeed, as you say, to put the extra features in a nice UI in Qt.
Btw, the idea of providing n-up and others at QtDF internally was to do this in the QPrintPreview dialog. Makes much more sense to allow the user to move around page layouts visually, doesn't it? The implementation of the QPrintPreview dialog (using QPicture) makes this easy and cheap and no cups features needed, so cross-platform.
We can provide anything
We can provide anything QPrintPreview provides since KPrintPreview basically uses the Okular part so we have all those options available at less than 10 lines of our code, just need to make the actions shown and that's it
KPrintPreview
Just looked at the sources of the KPrintPreview, it essentially writes the output to a PDF and stars okular to show that. Then the user presses 'close' and has to press 'print' which brings up the print dialog for the first time
I think all KDE applications are better off using the QPrintPreview class instead which has many more features and much better thought out workflow. I mean,what if i see the print preview dialog and think; thats the wrong paper format.
I need to cancel, go to the print dialog, print it to real paper, go to the preview dialog to see what I did and... Wait, whats the use of the preview dialog again?
I also think its good to use QPrintPreview which uses QPicture so it works without Okular (or any other pdf reader kpart) installed ;)
In short; I suggest KPrintPreview to be deprecated and people use the QPrintPreview class instead.
Print Preview
@Thomas Zander: But "selecting Print from QPrintPreview produces a Print Dialog without the KDE enhancements" sounds like a showstopper to me. We work hard to add features to the print dialog in the KDE wrapper classes, showing a Print button in the print preview which doesn't bring those up just sucks.
not a showstopper
Your argument that its a showstopper is probably based on the assumption that you loose info. This is not the case.
What happens is that the print dialog is a front-end to update the data structure of what to print. If some GUI options are not shown then the features are not silently removed, they will just stay unmodified.
So, no info is lost, just the least used options are not shown on screen.
I vote for the revival!
As long as only a minority of the applications have the print preview activated (File -> Print Preview) there should be the old option reactivated!
See also: http://forum.kde.org/brainstorm.php#idea84727
Regards, Martin
bringing back the print-preview checkbox
I think everyone agrees its the best solution to have the checkbox back. The problem here is really that we progressed a lot from the KDE3 times where we could just assume that everyone owned postscript printers or had a system where this would be enough.
In reality postscript is hardly used anymore and people want all the features that are impossible to do using the now aging postscript. But because of us stopping to use postscript we loose the easy to implement print-preview feature because the new way of printing is just more complicated, yet much more powerful.
The ideal solution requires some research on how to make that checkbox replace the printing-backend to a QPicture and at the end of printing to show a dialog with the print preview, then if the user presses ok use the selected printer and spool the qpicture contents to it.