In light of Mark @sabdfl’s comment, if this is granted, it might be worth revisiting the decision on the same request for printing capability for GIMP and also allow @hellsworth to request it for Glimpse.
1 Like
This would be excellent. I’ve encountered Glimpse users wanting this autoconnect in Glimpse too.
2 Likes
@sabdfl as architect has said to grant this, thus overruling the vote provided that “we will expect maintainers and upstreams to do the work on their side when we have those facilities”.
@ted - you’ve stated wrt to portals that “an application can use portals to print if they’re on Ubuntu 18.10 and have all the portals installed. They’re not in main in 18.04 and not even in 16.04, much less 14.04 and the other distros that snaps claim to support. Until portals are a dependency of snapd applications can’t depend on them being there, so we’re forced to deal with things like cups-control.” Considering @sabdfl’s expectation if granting this, do you plan to move to portals (or another suitable API if it becomes available) when it is more widely available?
@Wimpress - can you comment on making the printing portal more widely available for (at least) Ubuntu 18.04 and forward?
@lucyllewy - with GIMP as a design program, you are stating that paper copies are a normal part of its workflow? If so, do you plan to move to portals (or another suitable API if it becomes available) when it is more widely available?
@hellsworth - with glimpse-editor as a design program, you are stating that paper copies are a normal part of its workflow? If so, do you plan to move to portals (or another suitable API if it becomes available) when it is more widely available?
Yes, which would also allow us to drop the home and removable-drives interfaces. We’ve investigated what is needed there and expect that the unreleased (at time of writing) gnome-3-3[46] extensions will have the version of GTKmm needed to support portals. I’ve currently switched the snap in the development branch of Inkscape over to using that gnome base using the candidate snapcraft.
If I can do that as a Snap package maintainer, and not an upstream developer (i.e. with only changes to the snap packaging without changing upstream’s code) then sure, I’d love to support portals in GIMP. If I cannot do it without modifying GIMP itself, then no, I will not add support.
Basically, I am not happy with carrying and maintaining a delta from upstream.
Granting auto-connection cups-control to this snap. This is now live.
As an aside, thank you for working with us while we refine our processes.
1 Like
FYI (cc @pedronis), I’ve also adjusted the ‘cups-control’ portion of Process for aliases, auto-connections and tracks to state “or design programs where printing is an expected part of the workflow. Granting requires a stated commitment from the developer that moving to a safer API will be performed (such as the Printing portal) when it is widely available”.
Perhaps @jamesh or @Wimpress can comment on what toolkits make the Printing portal available? Then perhaps you can evaluate if that is something that the snap can use.
1 Like
Sadly it isn’t just using the toolkits (at least for GTK). It depends on which API you’re using for the dialogs. For GTK you need to be using the “Native” named dialog functions to get portal support. I expect those to be the default going forward for new applications, but older ones probably haven’t switched and the API is ever so slightly different.
1 Like
If you’re willing to make explicit calls to the portal API, you could integrate support into a GTK 2 application. The libportal library would be a good place to start with:
There is header-only integration with GTK 3 and GTK 4 for handling parent window IDs (used to associate out of process dialogs), but it looks like the GTK 3 version may work with GTK 2:
https://github.com/flatpak/libportal/blob/master/libportal/portal-gtk3.h
The print API consists of two async APIs that you might be able to integrate:
https://github.com/flatpak/libportal/blob/master/libportal/print.h
An optional prepare_print() call that will pop up a print dialog, and return page setup details if the user decides to continue, and a second print_file() call that will complete the job.
If you don’t care about the page setup details, the prepare call can be omitted. In this case, the print_file() will instead show a print dialog to let the user confirm the job.
For us, going to the Native dialogs makes the most sense. The (resolved soon) issue was that 18.04 shipped with a GTKmm that didn’t have them. I expect there to be an LTS with them this month 