Yash is GSoC contributor at OpenPrinting, with the project “GTK Print Dialog: Modern dialog with built-in preview in main view”. He has investigated the problem and is working on a print dialog similar to the ones of Mozilla or Chromium or to the design idea presented in that thread.
Now Emanuelle Bassi and @adrianvovk told in that thread, during the discussion of the license problem with the Poppler-based previewer, that the print dialog will be completely removed from libgtk and only be in the portal and GTK apps will use the portal, and in the portal a more modern print dialog with embedded preview will get implemented.
Then I have asked the following questions to Adrian:
If all GTK/GNOME apps (also if classically installed, no Flatpak or Snap) will use the portal, does it then still make sense to modernize the GTK print dialog? Or should we better invest Yash_kumar_kasaudhan 's second half of his GSoC time in him working on implementing the new design of the portal backend?
Adrian only answered:
Great question. I’ll bring it in front of the release team
We need a reasonably quick answer here to know how Yash should continue his GSoC work. Should he apply his work to the print dialog code in the portal? Or do you prefer that he does not contribute here and I reassign him to something completely different? I do not want that he is working on something which will not get used or “wait for further instructions” for a longer time.
Just to clarify this, OpenPrinting submitted and started a GSoC project, that is for GTK/GNOME and did not get initial confirmation from the community the work is for?
I remember randomly getting a GSoC proposal as PDF via mail and I neglected it because it was past GSoC application period and the proposal did not make any sense.
I am pretty sure we do want to rework how print preview works in the long run. But the very first step here would be to get input from the design team and to plan how that integrates with portals. It would make sense if the preview would be shown immediately in the print dialog and the adjustments to settings would update the preview. But there are many many details that have to be clarified for this first. There is no way this can be done within a few days, probably not even within a few weeks.
I understand GTK developers are planning to remove printing support in GTK 5. So yes, the dialog would eventually need to move from GTK to the portal itself. But GTK 5 is not exactly imminent. If this does eventually happen, then I imagine we’d just Ctrl+X the code out of GTK and Ctrl+V it into the portal backends. So I wouldn’t worry about this too much. Doesn’t seem like it should affect your plans?
If all GTK/GNOME apps (also if classically installed, no Flatpak or Snap) will use the portal, does it then still make sense to modernize the GTK print dialog?
The portal itself uses the GTK print dialog, so GTK seems like the most sensible place to do the work. Moving the dialog to the portal backends doesn’t help you because both xdg-desktop-portal-gtk and xdg-desktop-portal-gnome use the same license as GTK itself, LGPLv2.1+. So regardless of where the dialog lives, you can’t use poppler. Which is probably a good thing, because poppler is a security nightmare.
Please also keep in mind that design changes to system dialogs are unlikely to be accepted unless you’ve been coordinating with design team and are working off of an existing mockup.
My thinking was we’d pull the portal out of xdg-desktop-portal-gnome and instead put the print dialog directly into Papers, similar to what we’ve done with the file browser and Nautilus. This seems especially appropriate given Papers’s plan to figure out how to sandbox their Poppler rendering.
Alternatively, we could have a dedicated print portal that’s licensed in a compatible way with Poppler.
Alternatively alternatively, we can relicense xdg-desktop-portal-gnome as GPL. It’s not a library, so LGPL is probably an inappropriate license for it anyways. But even if we don’t relicense, we can actually link Poppler against xdg-desktop-portal-gnome. It’s just that the resulting binaries would have to be distributed under the terms of the GPL rather than LGPL. We can’t do the same trick with GTK since GTK is actually a library and LGPL is used to allow proprietary apps to use GTK (and linking to Poppler would force us to distribute under the terms of the GPL and thus make GTK unusable for proprietary apps). But also IANAL and this is just my layman’s understanding of licenses.
Moving the portal to Papers sounds like a good plan.
Distros will have to subpackage things carefully, though. Distros will want to allow users to appear to be able to uninstall Papers by putting desktop file and appstream metadata into a separate package, even though the actual application will be always installed to provide the portal. (E.g. look at how Fedora handles Epiphany packaging. The app is always installed because it’s theoretically a dependency of GNOME Software, although I’m not sure if that’s really true. But it looks like it’s not always installed.)
Yes, Papers might be replaced by users. Furthermore, I doubt that a PDF viewer is considered a system app, unlike a file manager, even though PDF is perhaps more used these days. Papers is also not entirely sandboxed. A specific viewer for the specific task is preferable.
Note that it is also necessary for proprietary apps to be able to use the print portal. So, if there is a license problem due to the use of poppler, then a solution is needed (but is there really a problem as portals are about requests, not using the code of a portal backend?)