Announcements

Help Wizard

Step 1

NEXT STEP

MPRIS Raise implementation is faulty and makes flatpak fail to raise window

MPRIS Raise implementation is faulty and makes flatpak fail to raise window

Plan: Premium

Country: Argentina

Operating System: Ubuntu 20.04, Fedora 32, Arch

 

My Question or Issue

 

The issue has been discussed at length here:

 

https://github.com/flathub/com.spotify.Client/issues/136

 

And here:

 

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3179

 

From a user POV the problem is: media controls are unable to raise and focus the spotify window when you click on the current song name.

 

There are two related causes:

 

1. MPRIS is not fully implemented, Raise does nothing at all. 

 

2. Because of how flatpak works, the desktop file for spotify is packaged as com.spotify.Client.desktop. But since Spotify itself is not packaging the flatpak, the name exposed in the MPRIS DesktopEntry property is still "spotify" and not "com.spotify.Client" as it should for obvious consistency reasons.

 

GNOME Shell media control uses an heuristic to solve and raise the app that first look for a <DesktopEntry>.desktop file and, failing that, calls Raise if CanRaise is not false. Now, both attempts fail for the flatpak: because of 1 above Raise does nothing, because of 2 spotify.desktop is not found.

 

Here is a list of alternative solutions you could implement (some of them are really easy):

a. Package the flatpak yourselves.

b. Provide some way to change the MPRIS DesktopEntry value, maybe a command line option, a configuration option, an environment variable, whatever.

c. Properly implement the Raise method.

d. Rename your desktop file to com.spotify.Client (following the desktop file spec recommendations) and expose that name in DesktopEntry.

 

Take into account that serving Ubuntu is not the same as serving Linux, you already provide a deb, now a snap, there are many non Debian based distros and some of them have concerns about the snap store. I'm not implying you should somehow do extra work because of Linux fragmentation, but helping *a tiny bit* (in particular, solution d above is trivial) to allow a third-party (flathub) build a 100% functional flatpak will go a long way.

 

Thanks.

Reply
1 Reply

(I have added what was here to my main post and I don't seem to be able to delete this)

Suggested posts