Thanks for putting these mock ups together.
Without trying to rehash the long discussions in the sprint, when interfaces are disconnected certain things will not work indeed, and that’s part of the point of having interfaces in the first place. The network example provided is a good one: disconnecting it allows the user to make an application local. A proper application will just report that the network is off, as that often happens for many other reasons.
For cases which are indeed less usual to disconnect for a normal user (say, “opengl”), I think what we should have is an ability to flag an interface as “advanced” in the interface model itself, so that GUIs can learn which of those should be separated out.
It’s good to remember that interfaces won’t necessarily come up connected, though. Some interfaces deemed dangerous and not fundamental for an application may in certain cases be left out of the auto-connection case. So we need to also think in terms of “Would someone want to connect it?” instead of just “Why would someone disconnect it?”. Having no good means of connecting such interfaces may easily backfire, as it increases the pressure of having the interface connected in the first place.
Finally, there are indeed interfaces that pretty much never make sense to show up. “core-support” would be one of them. That might be a different value in the same field that flags interfaces as advanced.
For example, something along the lines of:
visibility → default / advanced / hidden
This would be defined by the interface type itself (snapd code) instead of being a per-snap setting. Lack of a value would imply “default”.
Having additional metadata about how to show interfaces would be a huge help here. As per the content interface example a snap client can’t be 100% sure if this is something that is essential or optional.
We should make snapcraft help here so app developers set these appropriately and we don’t get a bad default experience.
For example, if you add an “x11” plug to your app snapcraft could warn when building the snap:
“You have used the x11 interface without a visibility tag, we recommend setting this to advanced so users don’t accidentally disconnect it”
Additional features we’d like to add to this GUI for safety:
- We’d like to have a “reset to defaults” button to allow users to get their snap back to the installed state. This would require a “default” field or similar that would show what the default slot a plug is auto-connected to.
- We want to warn the user about common mistakes. e.g. if the network plug is disconnected we’ll show some information in GNOME Software to say something like “This app doesn’t have network access and may have limited functionality”. This will hint to users if they’ve forgotten this is disabled or made a mistake how to correct it.
I don’t think @niemeyer is suggesting this has a plug property in
snapcraft.yaml for the snap application, but rather part of interface definition in
I think if we add that has an interface property, the result will be that a lot of snap app will set all their plugs to
hidden, resulting in no possibility to disconnect anything.
Ah, right. This solution is mostly just moving the policy from the client to snapd (which has advantages and disadvantages).
There’s two cases which this solution doesn’t work well:
- Non-core interfaces which might be essential / advanced (e.g. platform content interfaces).
- Interfaces that may be essential for one snap (e.g. network access in a network scanner) but not another (e.g. network access to the calculator).
Good use case on the content interface for platform snaps. Right now, if the app is ran as a CLI tool, it will warn about it, but we don’t have any graphical equivalent when run from their .desktop file.
Let’s see what Gustavo thinks about it…
This is not moving from the client to snapd, since that information was never in the client. This is simply storing the data where it belongs, next to everything else about that interface.
Network would definitely not be “advanced” whether for a scanner or for anything else. If you cut out network access to an application, the exact same would happen as if your laptop was offline.
I don’t mind too much whether the content interface shows up in “default” or “advanced”, as long as it shows up. There will likely be one option in most cases, or a couple if one installs two or three themes on the same system for example.
A client has to interpret the interfaces to display them in an appropriate way in a user interface. Some decisions that can be made are:
- Is this interface appropriate to the user in this context (e.g. should the core
core-support-plug be configurable?).
- What does this interface mean in the context of the snaps it connects? (e.g. what does it mean to disconnect the
network interface on a network scanner or a calculator?).
- What is the best means of controlling this interface (switch, combo box, drag lines between boxes?)
- What is the best way of describing this interface (where to position it? what text and icons to show?)
Interfaces currently contain a label and @niemeyer is proposing they contain a flag indicating their suitability for display (for core interfaces only).
The advantage of such a system is that clients are relatively simple to write and don’t need a table of labels and flags to display them. The disadvantage is snapd doesn’t have the context of the client so it can’t tell what wording is appropriate for the label and what is advanced for the user. The client still contains information about what controls and icons to use. Any of this information could be moved between snapd and the client . There is no exact place where the data belongs; we have options with advantages and disadvantages.
The content interface can be used for many things including:
- A set of core libraries shared between snaps.
- Optional data files, e.g. themes.
I don’t think this can be easily categorised into either both “default” or both “advanced”.
Brainstorming some possible ways forward:
- We decide the content interface is too general and make some more specialist content like interfaces with limitations, e.g. “theme”, “platform”.
- We allow the developer to provide hinting information about some or all plugs so that they can be more easily displayed.
- We make clients have a small table of known common interfaces (e.g. the Ubuntu platform). This would cover the majority of cases where users could be confused.
- We decide the content interface is not suitable for platforms, and use one of the new snap types in development.
I can see the value in an interface type specifying a default visibility, but it isn’t clear to me that every app would treat an interface the same way.
One app might be well behaved and continue functioning when you disable the
network interface. A second one might essentially become non-functional. In the first case, it might be safe to show the toggle to the user, and in the second you might want it set to advanced or hidden.
This is about all interfaces rather than just for core.
Quite the opposite: snapd is the only place that has context about what is appropriate or not. It’s the place where interfaces are coded, and assertions evaluated. If we put that in the client tomorrow there will be a new interface and the client will have no clue about what to do.
A concern I have about developer hinting is that different developers will make different choices which could be confusing for users. “Why is ‘network’ in advanced for the calculator but in default for the scanner?” (I turned this example around from the expectation that the calculator shouldn’t require networking but the scanner should to illustrate potential confusion).
Also, interfaces give access to the system and users can decide what to connect/disconnect so another concern I have is that a mal-intentioned developer might try to manipulate hinting to confuse users into making ill-informed choices. If we pursue developer hinting, lets keep this in mind.
I agree with @niemeyer for these reasons and the ones he listed.
snapd knows the mechanism of the interfaces but neither the context in which the developer chose to use it or how the client is displaying / controlling it. For the simpler interfaces this is less of a problem but as I have shown the
content interfaces is an example where we are lacking information to make good UI.
Currently this will not work because it will be killed while attempting to determine if network is available. Soon-ish (hopefully) we can start to make that be just an error, not application kill signal.
Well, it depends on how it is trying to check, but it is certainly possible the application will be killed, which is poor (but as you said, something that is being worked on).
Whatever interface or detail you pick, snapd will continue to have more information to make a good decision than gnome-software will. If the content interface is hard for snapd, it’s harder for gnome-software.
One thing I’d like to see that I didn’t see mentioned (apologies if I just missed it) is a user-friendly description of what the interface does that can be used by a GUI as a label or a tool tip. Many of these interfaces, while they mostly make sense to us by name, don’t make sense to your average user. In addition, we may also want to have one other piece of metadata with each interface: user friendly name.
@jhodapp There’s indeed much to be improved in that area, and we’re already starting to walk there. For example, the code currently in master already introduces further details such as summary and a documentation URL. We’re aiming at having topics in the forum to cover particular interfaces, similar to what we’re doing with the content interface.
That sounds good. I like what I see in the content interface documentation. However, why is this documentation on the forum and not on our central place for documentation such as this page for interfaces? It’d be less confusing for a user to find in my opinion. But again, well done on writing that documentation page…docs of that level are sorely needed.
@jhodapp Please see this topic for more background.
KDE Discover in Plasma 5.13 (releasing 12th June) will have a GUI for snap permissions (which means it’ll be becoming available in GNU/Linux more widely from 12th June)!