[mpris] [RFC] MPRIS2 Release Candidate

[Ian Monroe]

On Sun, Aug 8, 2010 at 8:01 PM, Alex Merry <kde at randomguy3.me.uk> wrote:
>  On 07/08/10 19:20, Lennart Poettering wrote:
>>
>> On Thu, 29.07.10 15:29, Mirsal Ennaime (mirsal.ennaime at gmail.com) wrote:
>>
>>> Hello,
>>>
>>> I would like to propose this document as a mpris 2.0 release candidate:
>>>
>>> http://www.mpris.org/mirsal/2.0-draft/spec.html
>>>
>>> Could you have a look at it and share any remark, concern, improvement
>>> proposal you have in mind ?
>>
>> A few comments:
>
> [snip]
>
> http://www.randomguy3.me.uk/mpris/
>
> http://gitorious.org/~randomguy3/mpris/mpris/commits/lennart
>
> I've ditched the property change signals in favour of the new D-Bus
> standard.  I've ditched the capabilities stuff in favour of booleans and
> optional properties (where getting a NotSupported error when you try to
> access a property tells you that it's not implemented).  Times are all in
> microseconds.  AdjustVolume is gone.

I still think a bit field for capabilities makes more sense. Some of
us use caveman tools like QtDbus where its not especially easy to make
multiple calls at once afaik.

Plus aesthetically, using a bit field for capabilities is something I
do in my own programming not so much because of efficiency concerns
but its just really easy to compare several bits at once and cleanly
communicate state to several parts of an application.

> The playlist stuff is the most drastic, and it has impinged on the Player
> interface (note that Metadata has been replaced with CurrentItem, which is a
> map of properties but possibly should just be a reference to the MediaItem).
>  Currently, there is only the concept of a current playlist.  There is no
> mechanism to list other playlists - I'm not sure where exactly to put that.
>  Do we want to expose a hierarchy, like MediaServer2, or a flat list (in
> which case it should be done with a PlaylistCount property, a ListPlaylists
> method and a PlaylistsChanged signal)?
>
> Let me know your thoughts.

I think only supporting the current playlist is fine. Even in a land
of tabbed playlists, that supporting only one playlist just makes
things easier for everyone. I still haven't seen a use case for
someone using MPRIS and wanting to adjust several playlists at once.
Even if the audio player has tabs, the simple clients of MPRIS
probably only care about the active one.

What's that point of this new MediaItem object? What was wrong with
the simple dictionaries (that appear to still be in use)?

Ian