Hi Nicolas,

Nicolas Fella:
> during my work on KDE Connect [1] I came across multiple players that do
> not support setting the volume (e.g. Spotify) or do not have a concept
> of volume at all (e.g. Gwenview [2] which is being patched with MPRIS
> support [3]). As far as I understand there is no way for the player to
> signal that controlling the volume is unsupported.

Well, actually there is a way, though the wording of the spec is
lacking. Players should not expose the Volume property as read/write if
getting or setting the volume is not supported. That way, clients can
use dbus introspection to find out what is supported.

> A canControlVolume
> property together with a canControlVolumeChanged signal would enable UIs
> to gracefully handle players that do not support it by disabling volume
> sliders when appropriate.

As much as I dislike the CanControl property, I understand that having
more granularity and runtime capabilities change signalling would be a
clear win. Do you think that signalling runtime changes of volume
getting/setting capabilities is absolutely required?

> This would lead to better user experience
> because otherwise the controller or player appears broken.

Yes, though let's try and fix it using dbus introspection first. If it
is not manageable, then we would need to change the spec.


🦄 mirsal

Attachment: signature.asc
Description: OpenPGP digital signature

MPRIS mailing list

Reply via email to