Hi Nicolas, Nicolas Fella: > during my work on KDE Connect  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  which is being patched with MPRIS > support ). 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. Cheers, -- 🦄 mirsal
Description: OpenPGP digital signature
_______________________________________________ MPRIS mailing list MPRIS@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mpris