[MPRIS] [RFC] MPRIS 2.3

[mirsal]

Hello !

On Thu, 2013-04-04 at 17:04 +0100, Alex Merry wrote:
> We've got some things proposed for a possible MPRIS v2.3 [1], and I'd
> like to get some feedback about which, if any, we want in.

I think these points are all sensible, though they are also rather
tricky in a way and there are quite a lot of things to discuss before a
draft can be produced.

> First up is a Mute property [2], as this is often orthogonal to volume;
> this should be on the Player interface:
> property b Mute
>  - emits PropertiesChanged

Indeed, though I think we should define how the media players should
behave with regards to the Volume property, that is, we should either
have all media players treating muting as orthogonal to the volume or
have changing the volume affect Mute in all of them.

Mute and Volume being orthogonal seems rather natural to me, although it
might force media players to keep some state for the only sake of the
mpris if they handle muting internally as simply setting the volume to
zero.

(That point is probably moot as these media players might simply choose
not to implement Mute instead, however I think the spec should not leave
any ambiguity about that)

> Second is metadata editing [3], on both Player and TrackList:
> method UpdateMetadata(in a{sv} updatedEntries, in as deletedEntries)
> - what happens to entries appearing in both arguments is undefined
> - wait for PropertiesChanged on Metadata to see if it worked
> property as EditableMetadataEntries
>  - emits PropertiesChanged

This looks racy to me.
Maybe the old value should be supplied along with the new one ?

I don't really like the fact that there would be no way to detect
failure besides an arbitrary timeout (adding tracks has the same issue
though and there might not be much we can do) 

> Third is HasPlaylists, which should make it easier for clients to see
> whether there is a Playlists interface implemented (fewer round trips if
> they use GetAll).  Not certain whether this is worth it, but we already
> have HasTrackList.
> property b HasPlaylists

I think the right question to ask is: Would changes at runtime need to
be signaled ?

If not the case, then dbus introspection should suffice.

> Fourth is a variant of Raise with a timestamp, which helps avoid
> focus-stealing prevention in window managers.
> method RaiseWithTimestamp(in x timestamp)

Yes, that is definitely needed, however RaiseWithTimestamp as a name
would probably feel very awkward to client application developers not
familiar with focus stealing prevention mechanisms' implementations.
Maybe calling it something like Focus and explaining the difference in
terms of effects (merely requiring attention in the case of Raise with
focus stealing prevention vs sending the to the front unconditionally
for Focus/RaiseWithTimestamp) would be a bit better.

> - arg is unix timestamp of the input event that triggered the call
>
> property b HasRaiseWithTimestamp
> - introspection parsing sucks; use in combination with CanRaise

I agree that it sucks though the bindings should get fixed instead of
the MPRIS working around their lacks.

I don't think it makes sense for this to change at runtime independently
of CanRaise.


Thanks!
best,

-- 
mirsal 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mpris/attachments/20130405/946c63e7/attachment.pgp>