Mpris can not be used with Snaps

[jriddell]

MPris is the handy spec for exposing a dbus interface from a music or video app so outside apps can control the playing. KDE’s Plasma desktop has good integration of this where you can right click on the app’s entry in the panel task manager and choose Play or Stop etc. But Snaps break it

The .desktop file is mangled to stop clashes so spotify.desktop becomes spotify_spotify.desktop.

qdbus org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.DesktopEntry
spotify

MPris spec says “The basename of an installed .desktop file which complies with the Desktop entry specification, with the “.desktop” extension stripped.”

Please fix this so I can play my music again. A world in silence is a sad world. Either install a sane desktop file or report a correct identity on dbus.

[sergiusens]

snapd is what handles the provisioning of the desktop file, so moving that category.

[zyga-snapd]

This is tricky to fix:

• we must mangle desktop file names because we have no other association as to which snap file provides which desktop file
• snapd cannot mangle the DBus protocol in any way

The only way to fix this would be to preserve the original desktop file name and handle conflicts among snaps but I don’t know if that is a workable proposal.

CC @mvo

[sergiusens]

The rule could be as easy as the one for apps.
If desktop_file_name == snap_name then keep the name

[jdstrand]

We have a mpris interface that works here on gnome-shell. Have you tried this interface: The mpris interface ?

[jamesh]

Looking at the MPRIS specification, it just states that music players should pick a unique bus name beginning with org.mpris.MediaPlayer2.; there doesn’t seem to be any mention of desktop file names. So am I right in thinking this constraint is a KDE Plasma specific addition to the protocol? Player controls for running snapped music players show in gnome-shell, but it doesn’t seem to be trying to associate it with the original app.

This would definitely need some changes on the snapd side to support properly: it isn’t something that can be fobbed off to the snap maintainer. For example, lets say that the Spotify developers decided to modify the snapped version of their app to request the bus name corresponding to their snap desktop file name. That would be org.mpris.MediaPlayer2.spotify_spotify, which is invalid due to the underscore.

Folding foo_foo.desktop down to foo.desktop might help in this specific case, but it isn’t the only point of friction for the current naming scheme. From what I can tell, the current naming scheme is based on the following requirements/assumptions:

1. it shouldn’t be possible for two snaps to claim the same desktop ID.
2. (unsure) The assigned desktop ID should be unlikely to conflict with applications on the host system.
3. The specific desktop ID assigned to an application has no semantic meaning, besides being unique.

This is just another case where (3) is a bad assumption. Others that I’ve encountered include:

1. D-Bus activatable desktop files, offering a fast path for activating single instance apps or quicklist actions. In particular, this requires the desktop ID to be a valid D-Bus name, so the simple folding case isn’t enough.
2. Cases where an the desktop ID of one app is hard coded into another app or service. For example, gnome-settings-daemon hard coding the IDs it tries to launch when the user presses the “calculator” key on their keyboard (currently patched in Ubuntu).

If we are going to change how this works, it’d be good to get some agreement over what the requirements actually are, and how they interact with other snapd features. For example, is it okay for parallel installs to break for apps that say their exact desktop ID is important?

[sitter]

@jamesh

Looking at the MPRIS specification, it just states that music players should pick a unique bus name beginning with org.mpris.MediaPlayer2. ; there doesn’t seem to be any mention of desktop file names. So am I right in thinking this constraint is a KDE Plasma specific addition to the protocol? Player controls for running snapped music players show in gnome-shell, but it doesn’t seem to be trying to associate it with the original app.

https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry

Since there is some confusion on what this is used for let me explain a bit more: In plasma the taskbar entries of applications have context relevant actions. In the case of an MPRIS-enabled application they contain media control buttons. To know which taskbar entry has which bus name the DesktopEntry property of MRPIS is used, if it is not set or not correct the task bar entry of the application have no control buttons.

Plasma also has a player control widget but that doesn’t care about the DesktopEntry, I expect gnome-shell’s thingy is more akin to that.

taskbar:

widget:

[jamesh]

Okay. So is the behaviour @jriddell described what happens when the MediaPlayer2.DesktopEntry property is absent? Or are we talking about snapped applications setting DesktopEntry to the wrong value?

Either way, it is still another example of applications wanting more control over their desktop ID. An application setting this DesktopEntry property will probably use a compiled in constant that won’t handle parallel installs, for instance.

[sitter]

@jamesh

So is the behaviour @jriddell described what happens when the MediaPlayer2.DesktopEntry property is absent? Or are we talking about snapped applications setting DesktopEntry to the wrong value?

The latter. As per the dbus call he posted the DesktopEntry is set to spotify but the mangled file on the disk is spotify_spotify.

@jamesh

DesktopEntry property will probably use a compiled in constant that won’t handle parallel installs, for instance.

Yep, that’s usually how it’s done.

@jamesh

This is just another case where (3) is a bad assumption. Others that I’ve encountered include:

Compiling in the desktop file name is actually a common occurrence I think. A notable example of this is actual API in both Qt and KDE core libraries: https://doc.qt.io/qt-5/qguiapplication.html#desktopFileName-prop and https://api.kde.org/frameworks/kcoreaddons/html/classKAboutData.html#a112d2fc20c31e7847995930e030cc67b

This hint is used to facilitate binary-desktopfile mapping in Plasma’s window manager, the taskbar to resolve better (?) icons and I think the task manager (to differentiate user-applications from random system-processes). As I recall the hint being accurate and resolvable is actually required for application icons getting properly resolved in Plasma-Wayland sessions.

So, yeah, the no-semantic-meaning assumption is pretty wrong

[jdstrand]

@jamesh

For example, is it okay for parallel installs to break for apps that say their exact desktop ID is important?

Thus far we’ve said parallel installs are out of scope for DBus since the parallel installs require to bind to the same name but only one can win.