Review Request: Add MPRIS2 support to JuK

[Eike Hein]

> On April 20, 2012, 12:31 a.m., Eike Hein wrote:
> > You currently can't commit it, since the kdemultimedia repositories are still locked.
> > 
> > And to be honest I'd be slightly miffed if this went in over my version, since, well, I did get there first. I also don't like some aspects of your implementation, e.g. the superfluos extra abstraction of generating adaptors from XML that subsequently need to be backed by nearly-identical classes anyway. I also don't think there's -that- much use to caching the values in the property system since the spec largely avoids the need for polling (due to PropertiesChanged) and so dynamic return value computation shouldn't make for a big difference, save for nicer code.

Ah, I also want to add that I disagree with mpyne's decision to use _HH encoding for the track ids. Michael really wants the file URL in there because it means he can reconstruct it from a request, but because D-Bus imposes a 255 character limit on path components I find using the URL too brittle and went for a SHA1 hash instead. And also, since the TrackList interface spec demands uniqueness even for duplicate entries of the same file in a playlist, using the file URL alone will not be good enough anyway.


- Eike


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104681/#review12696
-----------------------------------------------------------


On April 20, 2012, 12:19 a.m., Alex Merry wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104681/
> -----------------------------------------------------------
> 
> (Updated April 20, 2012, 12:19 a.m.)
> 
> 
> Review request for KDE Multimedia and Michael Pyne.
> 
> 
> Description
> -------
> 
> This adds basic support for MPRIS2 to JuK (http://specifications.freedesktop.org/mpris-spec/latest/)
>     
> Some (optional) things are still unsupported as I have not figured out how to make them work.  Notably, it is not possible to seek, as the naive implementation (calling PlayerManager->seek()) behaves strangely (the existing D-Bus interface doesn't support seeking, either).
> 
> The existing collection interface is not replicated.  Most things from the existing player interface are implemented in this MPRIS2 interface (I think the only exception is that MPRIS2 does not have an "album random" option).
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 9bd57f6c08abd9b144b0abc1775702284d6af753 
>   mprisproxy.h PRE-CREATION 
>   mprisproxy.cpp PRE-CREATION 
>   org.mpris.MediaPlayer2.Player.xml PRE-CREATION 
>   org.mpris.MediaPlayer2.xml PRE-CREATION 
>   playermanager.h 0eec655b487c5e0e37856b39e128087038987f05 
>   playermanager.cpp 54f601d19f801327f45b3157ed090aa785370583 
>   volumepopupbutton.h 6fb621b10c9a29f11d66869aac6451ed52935d79 
>   volumepopupbutton.cpp 76bd95d8e8713ace3afcba0ee510fdb19d6777b3 
> 
> Diff: http://git.reviewboard.kde.org/r/104681/diff/
> 
> 
> Testing
> -------
> 
> Tested using the MPRIS2 tester application (http://github.com/randomguy3/mpristester).
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20120420/cd971bb1/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia