With the modernization of the print dialog we want to make its operation more intuitive, and the biggest awkwardness in UX is that if you click “Preview” the dialog closes and in the preview you cannot return to the print dialog if you want to change something instead of sending it to the printer.
A preview is to check whether the printout will look like as the user desires. It is natural that often the user sees that it is not what they want and so they want to go back and do changes. This path is missing in the current workflow. The preview has only options to send the job off to the printer or to cancel.
So ideas came up to add a “Back” button to the preview to get back into the print dialog (re-open it), but the previewer being a separate package (due to license reasons) makes the approach difficult.
One quick and easy solution working with any external PDF viewer would be to keep the print dialog open when clicking on “Preview”. The user then does either do changes or prints by the Ui of the still visible print dialog. The print dialog could kill the previewer when it closes, either when the user prints or cancels. Even better would be if the dialog re-sends the PDF to the open PDF viewer when the user makes changes (option settings or destination printer), if the PDF viewer supports it.
The final goal of the modernization project is to get a dialog as we see in Mozilla (Firefox/Thunderbird), Chromium, or LibreOffice. Here the preview is embedded in the main view of the dialog and permanently visible, updated on any option/printer change the user does. This would require a PDF previewer which
- can be embedded in a GTK app like the GTK print dialog
- can get sent a new PDF at any time and immediately displays that new PDF without closing and re-opening its window
- is supplied in a separate package/GitLab repo due to the different license (AFAIK libgtk is LGPL and Poppler-based previewers are GPL)
If it is possible to embed arbitrary desktop apps (also using non-GTK toolkits) in a GTK app (here the print dialog) then the embedding would not be a big problem.
Important is also the updating, that you can send a new PDF to the running previewer and the previewer replaces the PDF which it is currently displaying by the new one immediately, and keeps displaying the page which was selected.
If there is no suitable previewer, we need to write a new one, with GTK as GUI toolkit and Poppler as renderer, which is embeddable and accepts receiving new PDFs. It should have its own repo in the GitLab of GNOME/GTK, published under GPL.
The GTK print dialog should handle the previewer’s absence gracefully, displaying without preview if the previewer is missing but making the user aware that with a PDF previewer they get a preview.