Open DarkArc opened 6 years ago
Does a non-flatpak'd Spotify work?
Do you have any more details how this is implemented?
Yes, it works using the normal deb on both Ubuntu 16.04 and 18.04 (this is what I've tested anyways). It uses MPRIS2.
Here's the commit that introduced basic support: https://cgit.kde.org/plasma-desktop.git/commit/?h=v5.12.0&id=d3e7a1985b7fd769514e1cbd8cf54dafa26863ae
Additional commits can be found in this search result set: https://cgit.kde.org/plasma-desktop.git/log/?h=v5.12.0&qt=grep&q=task
EDIT: Also, thanks for the speedy reply :)
MPRIS does work here, but it is very janky and will disappear while running sometimes.
There has to be another detail that is different.
It is just getting the wrong name:
+ // MPRIS spec explicitly mentions that "DesktopEntry" is with .desktop extension trimmed
+ var desktopFileName = launcherUrl.toString().split('/').pop().replace(".desktop", "")
We can't easily fix that, sadly.
We could implement a proxy but its a bit of work.
Hm... So are you thinking this would be an issue for any flatpak'd app? I wonder if this would be better patched at a flatpak/kde level depending on what's going on?
It is an issue for all apps that renamed their desktop file. We can try to get upstreams to change their mpris names too for Foss apps. The problem here is just that Spotify is proprietary and we are doing the renaming. KDE could work around this with a Flatpak specific check but I don't know if they would appreciate that hack.
Any news?
What you see is what there is.
We could implement a proxy but its a bit of work.
What would that take? Really the only thing we would override is the desktop id that it's sending. This is also the reason you can't raise the flatpak'd Spotify in the default GNOME shell MPRIS controls.
What would that take? Really the only thing we would override is the desktop id that it's sending. This is also the reason you can't raise the flatpak'd Spotify in the default GNOME shell MPRIS controls.
Not trivial I believe. Here is an example of a dbus proxy: https://github.com/flatpak/xdg-dbus-proxy/blob/master/flatpak-proxy.c
It does a lot more than we need though so maybe this could be done in a 100 lines of Python or something but I've not looked into it.
Could we and/or wrap the hole application in a Gio.Application
? That might solve a lot of paper cuts.
I'm not sure what that changes, but either way you have to proxy the data to the real mpris service.
I'm not sure what that changes, but either way you have to proxy the data to the real mpris service.
Maybe issues with opening multiple instances, not having the correct icon in the pulseaudio volume control. And possibly make it so it will actually open and play the spotify mime-types.
It's probably more work then it's worth but I'm a gluten for punishment.
We have no way of focusing the existing instance (well X11 grossness) or passing URLs to the existing instance. Upstream needs to fix that.
We have no way of focusing the existing instance (well X11 grossness)
The activate method would handle that for us. Basically it creates a new instance if there isn't one already or focuses the app if an instance exists.
in do_activate()
You would basically check to see if there's a window already just like Pithos.
passing URLs to the existing instance.
Spotify's OpenUri MPRIS method actually does work. It's just a matter of wiring it up so that a passed uri is feed to that.
The basic idea is to make a filtered Dbus activatable wrapper for Spotify.
It would also get rid of that janky script to set the widow border dark.
On the subject of the icon not showing up in the pulseaudio volume controls wouldn't that be a matter of simply adding something like this to finish-args
in com.spotify.Client.json
:
"--env=PULSE_PROP_application.name="Spotify"",
"--env=PULSE_PROP_application.id="com.spotify.Client"",
"--env=PULSE_PROP_application.icon_name="com.spotify.Client"",
"--env=PULSE_PROP_media.role="music""
Scratch that:
--env=PULSE_PROP_application.
anything doesn't work because of the period.
But changing:
/app/extra/bin/spotify --force-device-scale-factor=$SCALE_FACTOR "$@" &
To:
env PULSE_PROP_application.icon_name="com.spotify.Client" /app/extra/bin/spotify --force-device-scale-factor=$SCALE_FACTOR "$@" &
in spotify-bin does work to set the icon correctly in the GNOME sound settings at least.
I'll put in a PR.
Spotify's OpenUri MPRIS method actually does work. It's just a matter of wiring it up so that a passed uri is feed to that.
I didn't realize that, ok then this becomes much more doable.
I didn't realize that, ok then this becomes much more doable.
Yep you can pass this "https://open.spotify.com/track/2NdIe95VMTVifMkiKQUja8" for example to the OpenUri method and it will direct the Spotify UI to Metallica - Crash Course in Brain Surgery but it doesn't start playing it as you would think it would do. In my mind OpenUri should start playing the song if Spotify is already playing. Anyway that works for playlists and albums also.
But if you try the open in desktop link in the Spotify web UI it will start a new instance of Spotify.
I almost wonder if I couldn't hack together a fully functioning MPRIS implementation TrackList and PlayLists and all using the spotify connect web API?
I can at least probably fix the lack of volume controls by tying the dbus filter proxy's volume to pulseaudio's volume.
KDE will normally provide right click options for apps with audio playback in their taskbar entry. This does not happen with the Flatpak version.
This functionality has been available since Plasma 5.12 https://www.kde.org/announcements/plasma-5.12.0.php (See the "Task Manager Improvement" section)