Inkscape autoconnect cups-control

[cjp256]

As a follow-up, I propose to reduce future contention in future requests by formalizing a written policy that is minimally subjective and easily repeatable. If this exists, I could not find it.

For example, to request <interface> auto-connect:

1. Is application publisher considered trusted by the Snap Store?

<instructions on how to become one>

2. Has publisher agreed that they are in accordance to with the <access control policy for authentication keys which can push to store>?

This agreement would help minimize the risk that an unauthorized user can obtain the keys to push an unauthorized <snap> version to the store. It may include consequences if it is discovered that the policy is not adhered to.

3. Does the snapcraft recipe perform a repeatable build in accordance to <version policy>?

This could be useful to automate validation of builds and provide an audit trail in case of abuse.

4. Does the requested auto-connect interface enable a feature that a reasonable user would expect to work?

That is, does the non-snap version expose this functionality to the user?

5. Are there alternatives to using the requested interface that do not impact “reasonable user” functionality?

• Are the alternative(s) documented?
• Is this request intended to be temporary?
• Has publisher agreed on path towards this implementation?
• Has publisher documented grievance on the recommended alternative approach(es)?

6. Is this application documented as a core, or security-critical snap?

Is there a documented reason to ensure this application is as hardened / locked down as possible for system security reasons? Presumably this would make the case harder to get auto-connect.

[jdstrand]

While I appreciate the added information, it hasn’t changed anything wrt my opinion. My opinion isn’t the only one of course and if you look back, I asked for an architect to get involved to potentially overturn the vote.

You provide a lot of reasonable points for usability and removing developer friction (which were acknowledged prior here and in other topics requesting cups-control), but you didn’t acknowledge the importance of the user’s voice in auto-connetions (to connect or not is dictated by snapd (the base declaration), the store (snap declaration) and the user (manually connect/disconnect) or acknowledge that this interface allows configuring printers which is beyond the scope of printing and what inkscape specifically needs. There seems to be a disconnect that this is about security trumping usability. snapd is a new system that is designed for usability, security, reliability, predictability, etc. CUPS does not currently have snap-integration such that it will allow only printing to snaps and so granting inkscape auto-connect, and by extension the ability to configure printers, might provide usability but is unexpected, which degrades security and predictability. Importantly, developers are in full control of guiding the users to provide a better user experience; inkscape is in a position to detect that the interface is not connected and tell the user what to do (indeed other snaps do exactly this), but apparently it still doesn’t do this.

If there was an interface that allowed just printing, then I would vote to auto-connect it (indeed, there is: the desktop interface that allows access to Portals). You said that snaps are competing with more usable options. You are perhaps referring to flatpak which allows access to the portal by default, not the CUPS socket. Snaps also have access to Portals and if they still aren’t working, someone should fix that.

Also keep in mind that all the reviewers attempt to consider your various points and more when voting and we attempt to be consistent and consider prior votes when voting on new snaps. The problem AFAICS with inkscape in particular is that people landed on different sides on if printing is core functionality in inkscape. There are reasonable arguments on both sides. The majority felt that it wasn’t core enough to outweigh diminishing the user’s voice and the predictability and security of the system. This vote has proved contentious so I asked architects to weigh in (cc @pedronis and @niemeyer).

There are many paths forward:

• inkscape could immediately improve the experience and detect if the resource is available and guide the user to the snap-store GUI or terminal command, like other snaps do
• an architect could overrule the vote and grant a snap declaration to inkscape for cups-control
• snapd could make it easier for snaps to detect if interfaces are connected
• snapd could provide APIs for the application to request a connection prompt
• the printing portal should be made to work if it still isn’t available, and inkscape to use it
• snapd/the system could provide a contextual prompt when the cups socket is accessed
• CUPS could be modified to be made snap-aware (eg, only allow printing if a new ‘cups-print’ interface is connected)

[jdstrand]

@cjp256

As a follow-up, I propose to reduce future contention in future requests by formalizing a written policy that is minimally subjective and easily repeatable. If this exists, I could not find it.

There is Process for aliases, auto-connections and tracks which discusses the procedure. Unlike with classic and base snaps which have formalized criteria, interface auto-connections are not codified because each request is unique and subjective and we want to maintain flexibility for change and new thought. That said, all the reviewers consider prior votes for similar requests which can be shown through forum research.

[cjp256]

Great points, thank you for sharing Jamie ! Very informative.

As far as other “more usable options”, I wasn’t quite narrowly suggesting flatpaks. I’m inclusive of any option for a user to obtain their software, but the bar is probably best set by the OS’ native packages (In Ubuntu’s case, the debs from the apt mirrors). If it works in the apt repositories, a user would (rightfully) expect it to work as a snap, particularly if the software center prioritizes the snap version over that found in the apt repositories.

As you suggest, there plenty of routes in which things may be improved. There has clearly been an incredible amount of amazing work done by the snap community to get usability as great as it is, across a massive range of projects. It truly is impressive. I’m personally advocating that if none of the technical solutions are immediately available in this case, perhaps we work with the inkscape community to find the optimal path for all parties going forward. In the meantime, an auto-connect does not seem unreasonable given the alternative (frustrated users, perhaps ending up using a wholly unconfined deb, and perhaps worse yet: apt remove gnome-software-plugin-snap or whatever post they come across on how to disable snaps).

I don’t think anyone here wants to see negative community feedback associated with snap packages breaking expected application behavior. If they decide that snaps aren’t worth the hassle, they’ll resort to another option. I know I have spent plenty of hours debugging why certain snaps aren’t working as intended - I don’t think that’s fair to expect that of our users (even if it’s just one short google search away)! Especially when we have a viable option on the table.

Anyways, enough from me. Have a great weekend!

[karl]

I read about 40% through this useless argument page. I abandoned Corel Draw and my VirtualBox running Windows 7 so that I could switch to Inkscape. When I started seeing how versatile Snap was I decided to install it on my new laptop using Snap. After weeks of scratching trying to get printing working, and finally coming to this page, I have decided that the people who make the decisions don’t care about the needs of the people who actually use the product.

I will revert back to install Inkscape the old fashioned way, and will slowly migrate ALL my apps back to the old APT system, which never failed me.

My work centers around designing stuff, then printing it to show the partners and get approval. Now I have to print to a pdf, then open the pdf in another app just so I can print it, and if I find anything wrong with the output product, I have to do it all again… it’s like slavery with an extra step.

In the words of Cartman “S**** you guys, I’m going home!”

[pedronis]

@jdstrand

snapd could make it easier for snaps to detect if interfaces are connected

we have now plans to implement snapctl is-connected PLUG|SLOT

@jdstrand

snapd could provide APIs for the application to request a connection prompt

we have discussed this option for later as well, it would tie into some form of “auto-connection: prompt” (not actual syntax) feature. Then the snap would have some snapctl command to prompt and possibly get the connection if the user agreed.

[sabdfl]

Hi folks. We knew when we started on sandboxing that future facilities would enable more fine-grained access control. It seems in this discussion we have made perfect the enemy of good. Giving Inkscape access to pprinting makes sense - it’s a design program, and paper copies are a normal part of the workflow there. Can I ask that we give Inkscape printing access now, while planning to offer more fine-grained facilities and saying clearly that we will expect maintainers and upstreams to do the work on their side when we have those facilities?

[lucyllewy]

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.

Request for auto-connection of cups-control to gimp

@reviewers, I’d like to request automatic connection of the cups-control interface for the gimp snap. Printing from a graphics editor is commonplace and expected behaviour. Users are already requesting such support, where I can tell them to connect it manually and document it somewhere, or we can auto-connect Feedback welcome, 's more so :-p Although we have this bug that says it doesn’t help, in which case: “huh?” (it seems to expose my own printer when I connect the interf…

[hellsworth]

This would be excellent. I’ve encountered Glimpse users wanting this autoconnect in Glimpse too.

[jdstrand]

@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?

[jdstrand]

@lucyllewy

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.

@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?

[ted]

@jdstrand

@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?

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.

[lucyllewy]

@jdstrand

@daniel - 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?

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.

[jdstrand]

@ted

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.

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.

[jdstrand]

@jdstrand

As an aside, thank you for working with us while we refine our processes.

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”.

[jdstrand]

@lucyllewy

@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?

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.

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.

[ted]

@jdstrand

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.

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.

[jdstrand]

@ted

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.

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.

Thanks @ted. @lucyllewy - perhaps you can investigate upstream’s plans wrt to this (or ask them)?

[jamesh]

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:

flatpak/libportal

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.

[ted]

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