[GSoC] UML of PlaySong functionality for MprisPlayer plug-in

Peter Grasch peter at grasch.net
Sat Jun 28 10:02:33 UTC 2014


On Friday, June 27, 2014 02:26:23 PM you wrote:
> Hi
> 
> > How about a class "Player", with an attribute "title". Then have a hash of
> > serviceName -> Player* in the command manager?
> 
> So, each serviceName will have an object of Player associated to it. The
> PlayerObject will have a mapping from title to trackID. I should handle the
> Tracklist dbus signals in the player class and create commands there. Have
> I understood right?
That would be my rough suggestion.
But as every player will have multiple playlists, I think it does make sense 
to also have a Playlist class that contains the actual track and have the 
player manage it's playlists. That way you closely resemble the actual 
situation and this should make it very easy to correctly associate and process 
the update signals.

> >>> How will you match up user input (“Play X”) to track ids?
> >> 
> >> If what I mentioned above is somehow realised, when creating a "Play X"
> >> command, I will have the title of the track (i.e X) and also the trackId,
> >> which I will pass to the MprisPlayerCommand (and also ofcourse the
> >> serviceName). Then I will use the trackId for goto method inside
> >> triggerPrivate().
> > 
> > Wait, you mean you want the user to *know* the track id?
> 
> No, user need not know track id. I think I couldn't explain it. "X" is still
> title
Yes. But how and where are you planning to resolve "X" to the track id?

Best regards,
Peter

Ps.: Congrats on passing the mid terms!


More information about the Kde-speech mailing list