Should we support channels in GNOME Software?

[robert.ancell]

We currently only gets snaps from the stable channel. Should we expose other channels in the UI?

[niemeyer]

Yes, absolutely!

This is a fundamental part of the experience of using snaps.

We also need to talk about interfaces. Being unable to connect them means going to the terminal for anything non-trivial.

And configuration!

What’s the roadmap for the graphic support for snaps looking like? @willcooke?

[willcooke]

As in GUI for connecting plugs / slots?

There’s a question here which you might be able to advise on:

Connecting plugs and slots in a GUI

I’m looking for some clarification in the current thinking on the user experience connecting plugs and slots in a graphical environment. At one of the previous sprints we decided on implementing a dialog in gnome-software that would give the user an option connect plugs as necessary [1]. Does this still match up with the current thinking? It also seems likely to modify these settings after installation we will need a dialog in the control center. One case of an interfaces in a graphical snap i…

Once we know the right direction we need to get Picks API integration and Classic snap installation finished, then it’s ready to be worked on.

[niemeyer]

Thanks for the pointer. I’ll look into that thread right away.

That said, the question was more general. We have a pretty rich and ever growing user interface. Do we have a clear roadmap for supporting at least the key aspects in some form? I’d guess not, given the answer?

[willcooke]

Ah, right, gotya.

So, we have our Trello board (with suitable GNOME Software filter applied) here:

That covers the work we want to get done this cycle. A few of those need some assistance to unblock them. The links are in the cards in the Blocked column. The cards should be in order of importance, but are subject to change. I’ll give you write access to that board so you can add comments there if you wish, but we’ll update them once we get replies to the various forum posts.

Also, if you or anyone in the team are free come along to the GNOME Software stakeholders meeting next Monday @ 20:00 UTC:

https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=OWh0Zm5hbGw2bGM3b2FqcDJ0dGhnNm92Z2tfMjAxNzA2MTJUMjAwMDAwWiB3aWxsLmNvb2tlQGNhbm9uaWNhbC5jb20&tmsrc=will.cooke%40canonical.com

and we can adjust the priority of the cards as needed.

Configuration is missing from that list though. So I’ll add it now and we can get the conversation going quickly.

[robert.ancell]

What we need is the vision of the desktop snap experience.

Where we are today:

• We’ve developed a library that gives compatible bindings to all the snapd features (snapd-glib).
• We’ve developed basic snap support into GNOME Software as our stop-gap solution until Unity 8 came along.
• We’ve added new snap features to GNOME Software as required (SRUing them to older releases when appropriate).
• Since Unity 8 was cancelled, GNOME Software has now become our permanent software installation experience, so we need to work out what features need to add (reflected in our Trello board, bug reports and forum posts).

Some of the challenges:

• It seems not all snap features will be useful to general graphical users (i.e. more appropriate to embedded devices / sysadmins). We need input on this to work out when we say “use the command line” or “use another tool” (we don’t necessarily need to put all features into GNOME Software).
• The architecture of GNOME Software requires us to add new concepts in a generic way. This makes is harder to add Snap specific features without some thought being put into them (and understanding how they might change in the future).