GNOME Software only supports running one application from a snap

Bug #1661590 reported by Simos Xenitellis  on 2017-02-03
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Snappy
Undecided
Unassigned
gnome-software (Ubuntu)
Medium
Robert Ancell

Bug Description

HOW TO REPRODUCE:

1. Install LibreOffice snap ('nonfree' tag) from Ubuntu Software.
2. Click on the 'Launch' button once you have it installed.

WHAT IS EXPECTED:
It should launch the LibreOffice wizard instead of any of Writer, Calc, etc.

WHAT ACTUALLY HAPPENS:
It launches LibreOffice Database.

WHY THIS HAPPENS?

Ubuntu Software probably picks the first listed command (libreoffice.base), as shown in

$ snap info libreoffice
name: libreoffice
summary: "LibreOffice is a powerful office suite including word processing and creation of spreadsheets, slideshows and databases"
publisher: canonical
description: |
  LibreOffice is a powerful office suite – its clean interface and
  feature-rich tools help you unleash your creativity and enhance your
  productivity. LibreOffice includes several applications that make it the most
  powerful Free and Open Source office suite on the market: Writer (word
  processing), Calc (spreadsheets), Impress (presentations), Draw (vector
  graphics and flowcharts), Base (databases), and Math (formula editing).
commands:
  - libreoffice.base
  - libreoffice.calc
  - libreoffice.draw
  - libreoffice.impress
  - libreoffice
  - libreoffice.math
  - libreoffice.writer
tracking: stable
installed: 5.3.0.3 (17) 374MB -
refreshed: 2017-02-01 20:51:51 +0200 EET
channels:
  stable: 5.3.0.3 (17) 374MB -
  candidate: 5.3.0.3 (17) 374MB -
  beta: 5.3.0.3 (17) 374MB -
  edge: 5.3.0.3 (17) 374MB -

The order in snapcraft.yaml is different, so probably Snapcraft is changing the order (it might assume that 'libreoffice' is 'libreoffice.libreoffice', so it puts it further down.

Here is snapcraft.yaml: https://git.launchpad.net/~bjoern-michaelsen/df-libreoffice/+git/libreoffice-snap-playground/tree/snapcraft.yaml?h=xenial

Michael Vogt (mvo) wrote :

Adding Robert - is there anything you need from snapd to supoprt this? I think provide all the information if there are multiple apps in a single snap now?

Will Cooke (willcooke) on 2017-02-07
Changed in gnome-software (Ubuntu):
assignee: nobody → Robert Ancell (robert-ancell)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-software (Ubuntu):
status: New → Confirmed
Robert Ancell (robert-ancell) wrote :

We see the multiple commands but there's no way to differentiate between them. At the moment we're just launching the first command in the list.

I think as a first step the order should be as the developer intended, so picking the first one is an appropriate default.

If we want to support launching multiple applications from a snap, then we probably need more metadata. For example we probably need:
- Some sort of description for each app
- We need to know if some apps are graphical and some are not (we're looking at the slots the snap requests to use this).

We also need to work out how to expose this in GNOME Software, either multiple launch buttons per snap or break the snap into multiple entries.

summary: - When launching a snap from Ubuntu Software, it runs the first command
- alphabetically
+ GNOME Software only supports running one application from a snap
Changed in gnome-software (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged

In the same way that we can provide multiple entries to /snap/bin/ it
makes sense to offer multiple .desktop files. Would that get you closer
to a great desktop experience?

Robert Ancell (robert-ancell) wrote :

snapd currently doesn't (directly) expose the .desktop files, but if we had those we could get a better experience.

OK, I'm +1 with that unless you have another suggestion. Could we put
the desktop file as an entry under the app command? I.e.

apps:
  foo:
    desktop: path/to/file.desktop
    command: bin/foo.py

One thing that seems awkward is the duplication of the command in the
desktop file and the apps stanza.

Simos Xenitellis  (simosx) wrote :

A note here that when you run "snap info libreoffice", the order of the commands actually changes every time you run it. I suppose that snapd does not have the order of the commands as given in snapcraft.yaml. That's what I get with snap 2.12

A workaround could be for Ubuntu Software to pick the shorter filename (for LibreOffice, that would be "libreoffice", the wizard, which is what is expected to run).

Robert Ancell (robert-ancell) wrote :

I would hope that snapcraft can be made to automatically populate the apps data by detecting the .desktop files. In this case, the command does seem redundant. If GNOME Software knew the .desktop file it would use that information instead of the command.

Robert Ancell (robert-ancell) wrote :

I opened bug 1663103 about not being able to determine which slots each app uses.

Gustavo Niemeyer (niemeyer) wrote :

Every application may already have an associated desktop file under meta/gui/<app>.desktop today.

Gustavo Niemeyer (niemeyer) wrote :

Another side note: there's no special meaning to the order of commands in snap.yaml. We can reorder it, and snapcraft can reorder it, so please don't take it to mean something specific as that'll easily break.

Gustavo Niemeyer (niemeyer) wrote :

@Mark: The command is not duplicated. The desktop file will call the actual command defined in the snap.yaml. It may provide additional arguments, but those will indeed be _in addition_ to the ones in snap.yaml.

Gustavo Niemeyer (niemeyer) wrote :

More food for thought on the above note: the desktop file cannot call the real underlying command by itself! That would break confinement. It calls the confined binary under /snap/bin instead, which is what the "command:" attribute specifies. So, necessarily respected.

Gustavo Niemeyer (niemeyer) wrote :

Robert: what do you actually need here? We already support multiple desktop files, and they already hold metadata. gnome-software can already inspect to see which of these is available, I believe? What are the missing pieces?

John Lenton (chipaca) wrote :

I should point out that there isn't a clear 1:1 mapping between desktop files and apps, and that some of the things mentioned here would impose this.

FWIW IMHO if gnome software needs to choose one app from a snap to run because of its own limitations it should choose the default app, the one that has the same name as the snap.

Mark Shuttleworth (sabdfl) wrote :

On 10/02/17 16:50, John Lenton wrote:
> I should point out that there isn't a clear 1:1 mapping between desktop
> files and apps, and that some of the things mentioned here would impose
> this.
>
> FWIW IMHO if gnome software needs to choose one app from a snap to run
> because of its own limitations it should choose the default app, the one
> that has the same name as the snap.

I don't think we should assume that GNOME Software should run *anything*
from a snap unless there is a .desktop file for it. Lots of snaps will
not be appropriate to run in a GUI.

Mark

Robert Ancell (robert-ancell) wrote :

The solution we ended up implementing to determine if an app is graphical was in bug 1595023.

It would be much better to get an explicit mapping of apps to .desktop files and use that.

Robert Ancell (robert-ancell) wrote :

GNOME Software currently doesn't actually introspect anything from the .snap directly. It uses snapd which I understand it is the desired design of snapd (I like this).

So what I need is:
- API in snapd to explicitly map which app has which .desktop file and how to get the contents of them.
OR
- Confirmation on the correct method to get a .desktop file given an app name.

I think the API in snapd is the best method as this allows any changes in the snap format to be handled in one place and works for all snap clients.

Gustavo Niemeyer (niemeyer) wrote :

Sounds good. We'll add something along those lines to the API.

Michael Vogt (mvo) wrote :
Changed in snappy:
status: New → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers