-------- Forwarded Message --------
Subject:        Re: [MPRIS] [RFC] CanControlvolume property
Date:   Tue, 6 Mar 2018 :05:02 +0100
From:   Nicolas Fella <nicolas.fe...@gmx.de>
To:     Mirsal <mir...@mirsal.fr>


On 06.03.2018 11:14, Mirsal wrote:
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.
Then the wording of the spec should include that.
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?
Not absolutely required, but there is at least one case where it would be useful. Gwenview is an image viewer that can expose slideshows to MPRIS. A image has no sound at all, so it would make sense to disable volume control here. Gwenview is also able to play videos, so if there is a video in the slideshow it would make perfect sense to enable the volume control here. This sure is an edge case, but given that MPRIS is worded with 'media', not 'music' in mind, it could also be applied to e.g. PowerPoint/LO Impress presentations, which would face the same problem.
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.


MPRIS mailing list

MPRIS mailing list

Reply via email to