This is the type of system I’ve been prototyping with the VLC snap. It scans the available plugs and shows those that a user would understand. It doesn’t show the plugs that are too complex / wouldn’t make sense to disconnect e.g. opengl, unity7, x11. We may even consider the network plug should be hidden too, as a user disconnecting network access from an app is likely to break it.
This could be shared with other GNOME Software plugins as the permission types can be shared.
That looks nice, but it’s also extremely limited compared to our interface system, and thus will offer a tremendous impedance mismatch that will be a constant pain and prevent things from working at all. These interfaces you mention, x11, opengl, etc, are fundamental and trivial to handle rather than too complex. What happens when somebody needs to decide whether to give X11 access to something that wasn’t auto-connected? Or what happens when there are multiple choices (e.g. two serial ports)? Interfaces aren’t just on/off… they connect something to something else, and we need to somehow be able to represent that.
I think that while our interface system, in general, is a graph, we could get started with a UI tailored for something that only involves unambiguous connections with the core snap in much the same form as depicted above. For other things snapd could provide connection opportunities but the UI would have to be different. As a simple approximation of a graph UI (which I personally think would be unwieldy for most users and is not necessary in simple desktop software) we could offer either on/off toggles or one-of-many selection/combo boxes with available choices supplied by snapd.
That seems to paint the system as more complex than it really is. If you are looking at a snap, it has a number of endpoints (plugs and slots) that may be connected to other things. For any one of those endpoints, there’s a well defined and very limited set of things that it can connect to. We should be able to make a pretty straightforward user interface for that without involving graphs.
As discussed at the Snappy Sprint (June 2017, London) the current plan forward is:
Here are some screenshots from the current interface tool prototype (obviously more iterations required). See http://github.com/robert-ancell/snap-interface-editor:
oh my giraffe is a graphical game. It requires network, graphics and sound and has these interfaces auto-connected:
Tents is an Ubuntu Phone app. It makes use of graphics and the Ubuntu Platform snap for libraries.
VLC uses many interfaces:
The core snap has one plug:
From this initial prototype a number of things stand out:
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:
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 snapd.
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:
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:
core-support-plug be configurable?).network interface on a network scanner or a calculator?).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:
I don’t think this can be easily categorised into either both “default” or both “advanced”.
Brainstorming some possible ways forward:
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).