← Back to team overview

indicator-sound-developers team mailing list archive

Re: [mpris] MPRIS 2.0 draft proposal


On Fri, Jul 2, 2010 at 12:12 AM, Mirsal Ennaime
<mirsal.ennaime@xxxxxxxxx> wrote:
> hello,
> A new mpris 2.0 draft proposal is ready to be reviewed, there in html
> format: http://www.mpris.org/mirsal/2.0-draft/spec.html
> You can get the source files in the telepathy spec format using git by
> cloning git://gitorious.org/~mirsal/mpris/mirsal.git and checking-out
> the 2.0-draft-proposal branch
> Best regards,
> --
> Mirsal

It all looks great and looks like solving the biggest problems in V1
but I have some questions

- Do you think it would make sense to make MPRIS be able to manage
more than 1 TrakList (as most of the players I have seen in the last
years) so the client can build a more complete UI that can support
more of the player features?
This can be done adding a property to TrackList say GetTracklists
which can bring a list of current open Tracklists and the currently in
use. Or GetTrackLists and GetCurrentTrackList the former that brings
the complete list and the later that brings just the current one. Then
we will need to add which playlist we are trying to interact to with
the current methods. (maybe this must be better managed with another

Having multiple TrackList we can also add a Collection capability
which will tell us if the playlist we are Seeing is the entire
collection so we can add tracks to it from the client.

- Is there a reason to not allow the client to change the metadata of
a track? It looks like TRACKLIST_CAN_EDIT_TRACKS is not used in the

I would like to propose a new state. Shuffle_State: Playing random
albums. This is it plays an entire album and when it ends, it search
for a random album and play it from the beginning to the end. (Exaile
implements this type of random and I find it awesome)


Follow ups