org.mpris.MediaPlayer2.DesktopEntry is 'spotify', but some distributors change the .desktop name

[aarsen]

Plan

Premium

Country

Serbia

Device

A desktop PC

Operating System

Operating System: Gentoo GNU/Linux 2.14
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.113.0
Qt Version: 5.15.11
Kernel Version: 6.6.8-gentoo-dist-hardened (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 3800X 8-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: AMD Radeon RX 6700 XT
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B550M DS3H

My Question or Issue

Hi!

Happy new year!  🙂

I have Spotify installed from Flathub (which I do realize is unofficial, but hopefully not too bad).  The distribution of Spotify carried on Flathub and installed by Flatpak installs the Spotify desktop entry as 'com.spotify.Client.desktop'.

However, as the Spotify client does not know about this desktop entry, it advertises itself as if it was installed under 'spotify.desktop':

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

This causes the KDE Plasma MPRIS2 interface to not display an icon for Spotify.

It'd be lovely if the client could somehow be instructed (via a SPOTIFY_MPRIS_DESKTOP_ENTRY env var, for instance) about what the name of the desktop file it is launched from is called and adjust org.mpris.MediaPlayer2.DesktopEntry  accordingly.

Should that be provided, I can work on wiring up whatever mechanism the client implements on Flathub.

Skimming through the desktop entry specification, I don't see an existing mechanism for .desktop client handlers to communicate desktop file names/IDs to the programs they run, unfortunately.

I have tested, by installing a spotify.desktop -> com.spotify.Client.desktop symlink into $XDG_DATA_DIRS/applications/ that the lack of this file is at fault for the original issue above.

TIA, have a lovely day, and year!

[pgomes]

Hey aarsen, can you specify which is the icon that Spotify doesn't display? I ask because I am a KDE/Plasma user, and the icon is correctly displayed at the task bar and tray icon

Those work regardless of .desktop file, or MPRIS. All it takes is the client to find an icon image with write name, at the write place. The rules of how the client are few. But for simplicity, the DEB package has those below.
Would there be such icon files, than the client will properly set the icon

/usr/share/spotify/icons/spotify-linux-128.png
/usr/share/spotify/icons/spotify-linux-22.png
/usr/share/spotify/icons/spotify-linux-24.png
/usr/share/spotify/icons/spotify-linux-64.png
/usr/share/spotify/icons/spotify-linux-512.png
/usr/share/spotify/icons/spotify-linux-32.png
/usr/share/spotify/icons/spotify-linux-256.png
/usr/share/spotify/icons/spotify-linux-16.png
/usr/share/spotify/icons/spotify-linux-48.png

If the icons are somewhere else at Flatpak, we can add paths to the search. Would that suit you?

[aarsen]

Hi!

Thanks for spending some time on this.

Here's a screenshot of the KDE media player control widget installed on the desktop failing to show the icon (but the same can be seen in the media player control tray widget).  Though the cursor is not visible as it auto-hides when I tap a keyboard key (in this instance, my screenshot shortcut), it is hovering over where the Spotify icon should be, and causes the alt-text 'Spotify' to appear (the little popup above the widget).

This, unlike the Spotify tray icon and the Spotify menu entry *is* fetched over D-Bus, via the MPRIS protocol.  In the case of Spotify, that happens via the DesktopEntry property I mentioned above, which then leads to KDE (and friends, presumably) to do a lookup over the XDG_DATA_DIRS to find the desktop entry and its icon.  That search fails as the desktop entry is not 'spotify.desktop' but, rather, com.spotify.Client.desktop.

I believe this can be correctly fixed by altering the contents of the DesktopEntry property, and hopefully the fix proposed above (an environment variable that can override the 'spotify.desktop' default) is not much trouble, and is effective.

If the DesktopEntry property cited the right name, this UI would look like:

Thank you again, have a lovely day!

[pgomes]

Hey aarsen, sorry for the delay. I have checked the .desktop naming spec. It actually recommends to use the well-known DBUS name (org.mpris.MediaPlayer2.spotify in our case). This is the change I am inclined on doing, since it follows the standard. The one you suggest, in our view, would be a hack to accommodate a non-supported/3rd-party distribution (Flatpak). Would I implement such change (use the DBUS name), would help you to get in contact with Flatpak developers, and ask them do properly name the .desktop file?

[aarsen]

Hi!

Thank you for taking some time for this.

In this instance, 'well-known name' actually refers to https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus

A well-known name is a D-Bus name not starting with a colon, not necessarily a name that is adopted in advance by a standard (which is confusing, to be fair..)

Flatpak only installs .desktops that match a certain pattern based on the app ID (which is not 'org.mpris.MediaPlayer2.spotify' on flathub), see https://docs.flatpak.org/en/latest/conventions.html#desktop-files

This is to prevent collisions and to give more descriptive filenames, but is also unfortunate in situations like these.

The reason I suggested the configuration option via env var like above is to avoid changing the name of the desktop file, as that could probably confuse desktops in some situations (e.g. user overrides to properties of desktop files).  I suggested the env var because it avoids that and should be, hopefully, fairly non-invasive to implement.

Thank you again, have a lovely day!

[aarsen]

If I may, since it's been a few weeks of inactivity, ping on this 🙂

FWIW, it came up on the Flathub issue tracker for Spotify (which, yes, I understand is unofficial).

I hope the change is simple enough - just allowing the DesktopEntry property to change should work.

To clarify again, the desktop file wouldn't need to be named "org.mpris.MediaPlayer2.spotify" to be a well-known name (consider, for instance, GNOME Music, which installs org.gnome.Music.desktop, uses the DBus name org.mpris.MediaPlayer2.org.gnome.Music, on which the interface org.mpris.MediaPlayer2 on path org/mpris/MediaPlayer2 has a property DesktopEntry returning, of course, org.gnome.Music).

A solution that follows the desktop entry naming recommendations would be to also use something like com.spotify.Client.desktop (which also matches what Flathub installs and so would fix the issue), but I am worried that'd break something on existing installs (e.g. autostarts) as suddenly spotify.desktop wouldn't exist, so I think the proposed env variable is likely a safer option.  But, if you prefer renaming the desktop entry, then this issue can also be resolved in that way (by using the name com.spotify.Client).

Thank you again, and apologies for the trouble.  Have a most lovely day!

[pgomes]

Hi Aarsen. I didn't have much time recently to look at the client. But this can be an easy fix. I don't link so much the environment variable solution. I probably will go with renaming the desktop file. This shouldn't be an issue, as long as the file is still a the correct place

[aarsen]

Hi!

Thanks - as long as the desktop file ends up being com.spotify.Client.desktop, and the DesktopEntry property is updated to match, that should, indeed, work.