Thanks for the suggestion. I’ve tweaked the text slightly to hopefully better reflect your ideas. It’s aimed at a high level for most ordinary users, who will need to know the ideas behind the plug and slot terminology we use.
I’d like to suggest that this page needs some screenshots to the GUI method to configure permissions, as well. My goal is to have one single page that I can give to people who are asking questions about snap permissions, slots, interfaces, etc, that shows both the friendly path that we expect most people will use as well as the detailed cli path that is available. As far as I know, there’s no single page that has both.
This blog post has a screenshot.
It also has a code block showing listing of permissions but not how to grant or revoke those permissions.
This page has the listing, granting, revoking, etc down well but doesn’t tell GUI users how to get the similar results by clicking on things.
Thanks
Thanks for bringing this up. It’s something I’ve been thinking about too, especially with the maturity of Software application for interface management. I do have it on my todo list, but I’ll make sure I create something over the next 2 week cycle.
The example “snap interface audio-playback” shows the slot name as “core”, but these days, it appears to be “snapd”.
While this page shows how to use “snap interface” to examine a specific interface, it doesn’t show the more general usage of “snap interface” and “snap interface --all”.
Also, that command supports the “–attrs” option, but the only interface I can see for which that makes any difference is “content”. Are there others?
system-files and personal-files should also be in that category…
1 Like
The “snap interfaces” command is deprecated in favour of “snap connections.” See:
$ snap interfaces --help
AFAIK snap connections still doesn’t list unconnected but available interfaces…
Thanks - that’s a really good point. I’ll update the text to say --all lists interfaces with either unconnected plugs or unconnected slots (but not both). I wish there was better output for this.
There’s all sorts of variations I wish were available, like a way to ask, “Which plugs and slots are used by a particular snap?” That sort of output would seem to be appropriate for the “snap info” command.
1 Like
Under “Slots and Plugs”:
“In the above output, you can see that Chromium, VLC and the Zoom snaps are connected to the Core audio-playback slot.”
No, what the output shows is that they’re connected to the “snapd” slot, but you can explain that that is synonymous with core or system.
1 Like
Under “Disconnect interfaces”, the command:
$ sudo snap disconnect vlc:audio-record :audio-record
I’m sure you can type just:
$ sudo snap disconnect vlc:audio-record
no?
Good point, thanks - I’ve updated the doc.
Seems like these two hyperlinks to the “Listing connections” and “Slots and plugs” sections are broken. Nothing happens when you click on either of them. The other section hyperlinks work however. I think the markdown just needs to be changed to the following:
* [Listing connections](#heading--listing-connections)
* [Slots and plugs](#heading--slot-and-plugs)
Urgh, thanks so much for letting us know. I’ve just fixed these.
A few suggestions for this page.
First, move the “Plugs and slots” section to the beginning, as it is the basis for the entire rest of the page; it makes no sense for it to be partway down the page.
Next, the two sections “Listing interfaces” and “Listing connections” document exactly the same commands: “snap connections” and “snap connections --all”, so it makes little sense to break that over two distinct sections, just cover that command all at once and show its variations.
On the other hand, in the “Plugs and slots” section, there is a passing reference to the “snap interface” command; that deserves its own section. Effectively, I envision two sections:
Investigating connections (“snap connections”) Investigating interfaces (“snap interface”)
or something like that, that seems to flow more smoothly.
Next, for “snap interface”, you should cover the “–all” and “–attrs” options, which raises the question – where are interface attributes documented? That’s why this command merits its own section; there are things to say about it.
Next, in the section “Disconnect interfaces”, I think you really need to emphasize the “–forget” option to disconnect. (Also, where is this information stored so it can be re-consulted? I assume snapd, but just want to confirm.)
Finally, there is no mention of “greedy” plugs, as documented here: Plug/slot declaration rules: greedy plugs. Should there be at least a reference or link to that page? And as I recall, the concept of greedy plugs is referred to as “arity”, but I don’t see that word being used a lot. Should that be the official descriptor of this concept?
Thanks for these excellent suggestions. I’ve done a quick pass to improve a few things, but I’ve also created a TODO to update this doc with your ideas. Thanks!
“arity” is used in the codebase because there have been discussion of allowing actual numbers for the arity/valence, but it might be a bit of a too technical bit of terminology to use it in the general docs especially if the only usage is the greedy “*” case atm. But it doesn’t refer to just greedy plugs, it refers to the allowed valance, the default is arity=1, but for that we have usually just mentioned unique/single in docs.
The “listing interfaces” docs say:
In the output to
snap connections vlc(see above),
However, the output of that command only appears further down below on that page, so that should probably be changed to “(see below)”?
1 Like
Thanks so much for letting us know. Now fixed.