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)