[MPRIS] Fwd: Re: [RFC] CanControlvolume property

[Nicolas Fella]

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


Hi,

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.
>
> Cheers,
>
>
>
> _______________________________________________
> MPRIS mailing list
> MPRIS at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mpris
BR

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mpris/attachments/20180306/4e297b01/attachment.html>