This might be a regression in GNOME-Shell.
The transition to libsoup3 (which downloads URLs) changed how it handles data:
URIs. I'd probably report it to gnome-shell. It will need to use Soup.uri_decode_data_uri()
.
It seems it is possible to encode data to a URL via base64 etc. (See example), but not every client supports it, e.g., gnome-shell
, as of the time of writing.
The issue mentions Qt clients, VLC and Audacious, that use cubic. I would recommend it as its just maps better to how humans hear volume.
I recently implemented volume synchronization Strawberry and would like to know if I should use linear or cubic for MPRIS2, I have been using linear until now. All other players I tested uses cubic in MPRIS2, but I assume this might be because these are all GTK and they have cubic volume slider, but the advantage with using cubic is that it will match the percent in the PulseAudio volume control.
It's unclear what the trackid
metadata property should be set to when the player doesn't implement the TrackList interface:
https://gitlab.gnome.org/GNOME/totem/-/issues/538
I've set it to /org/mpris/MediaPlayer2/TrackList/NoTrack
for now, but it might be better to have another placeholder value instead.
Adapted from https://lists.freedesktop.org/archives/mpris/2013q4/000064.html
gnome-settings-daemon, which handles media-keys in GNOME, got support (in GNOME 3.10) for MPRIS in addition to its own media-keys API.
This is the documentation for the gnome-settings-daemon API: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/blob/master/plugins/media-keys/README.media-keys-API and the API itself: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/blob/master/plugins/media-keys/gsd-media-keys-manager.c#L94
as you can see, we could replace all of that with MPRIS, apart from one thing, the "time" argument passed to GrabMediaPlayerKeys().
This is used for gnome-settings-daemon to know which one was the last focused (or last used) media player so that keyboard keys are forwarded to that player even if the player isn't focused.
I could track the last media player to appear on the bus, or the last one we sent events to, but that would mean that unfocusable players (the "daemon" kind) would get the benefit of that, and changing playback using the gnome-shell "Now Playing" feature wouldn't update that "last focused" variable.
Closes: #9
This is now implemented another way in gnome-settings-daemon: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/ae95b871d2ea4409a95c750d8ce63c9e5b29a6b8
I'd suggest adding a new Activate method that is about the same as Raise but with an a{sv} argument for options. We could then deprecate Raise.
correct
https://gitlab.freedesktop.org/mpris/mpris-spec/-/blob/master/spec/org.mpris.MediaPlayer2.xml#L6 < We are talking about this "Raise", right?
In order for a player to raise itself on Wayland it needs to use xdg-activation. The player needs to receive an activation token that it then can use to request that its window is raised from the compositor.
To do this the Raise method could be extended by a 'activation_token' parameter of type string
Most media players will have the image data for the album art already available as a pixel buffer; currently, implementors or MPRIS have to save the album art into some file and then set the metadata as an URL:
The location of an image representing the track or album. Clients should not assume this will continue to exist when the media player stops giving out the URL.
The metadata should include an mpris:artData
key that let you pass a bytes buffer (ay
) with the pixel data. The size of the data can be specified to be, at most, 256x256 pixels, like a thumbnail. It's perfectly fine to send that amount of data over DBus; it's likely less problematic than saving a bunch of pixels as a PNG in a directory and then having to load them all from another process.
Advantages:
DBUS_NAME_FLAG_ALLOW_REPLACEMENT
so it can't be accidentally replaced by a DBUS_NAME_FLAG_REPLACE_EXISTING
registration.Disadvantages:
Alternative solution is to not use method calls, but to emit a signal that each application must listen to and react to. That is, a callback mechanism: "who's there?" followed by calls to the originator "me, me, me!"
I raised this issue on the dbus mailing list and @thiago proposed that instead of media players making new names for themselves with org.mpris.MediaPlayer2
as a prefix, all media players should just request the name org.mpris.MediaPlayer2
without any additions or suffixes. All media players would then be able to be discovered by calling org.freedesktop.DBus.ListQueuedOwners
on the message bus with the string org.mpris.MediaPlayer2
as the message argument.
In addition to avoiding the issue with naming collisions, this solution can be implemented in clients in a single call to the message bus whereas the current solution requires clients to first get a list of all bus names from the message bus and then secondly filter it according to the known prefix.
Thiago Macieira's message here.
The MPRIS bus name policy requires media players to request a unique bus name which begins with "org.mpris.MediaPlayer2
". However, it puts no constraints on which names with this prefix that may be chosen (beyond the basic limits set by the D-Bus specification itself). This opens the possibility of two media players oblivious of each other requesting the same bus name, creating a naming collision.
This negates the purpose of D-Bus's reverse domain name notation which is to form a namespace (in this case the namespace identified by the string org.mpris.MediaPlayer2
) that is controlled by its notional owner (in this case this project, the MPRIS project) in such a way that no names authorized by the owner cause collisions.