Review Request: Add MPRIS2 support to JuK

Eike Hein hein at kde.org
Fri Apr 20 01:55:06 BST 2012



> 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.
> 
> Eike Hein wrote:
>     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.
> 
> Alex Merry wrote:
>     Fair enough - my fault for not creating a RR when I first ported this from Amarok last year :-).  I'll work on moving the work the other way, and filling in the missing parts of your implementation, then (yay, more testing...).
>     
>     I hadn't clocked the 255 char limit.  JuK actually doesn't allow you to put more than one copy of the same file in the playlist (I tried), so that's not an issue.
>     
>     The property caching was actually Aurelien Gateau's scheme for making it simpler to support the PropertyChanged signal.

Aye, thank you. BTW, mpyne and I (Sho_) are both online and in #kde-multimedia right now, might ease any coordination.


- 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/a1df4a26/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia


More information about the kde-multimedia mailing list