MPRIS2 dataengine

[Alex Merry]

So, the nowplaying dataengine sucks, and I've basically given up
maintaining it.  It's broken by design, causes lots of wakeups and
context switches etc etc etc.  Also, trying to support half a dozen
different ways of talking to a media player is crazy.

However, MPRIS2 [0] provides a solution.  All the kids are doing it
these days: Unity and Konversation, to name two projects, are
exclusively talking to MPRIS2-capable media players.  Amarok and VLC
have support for it, JuK and dragon will have support in 4.9, many other
media players either support it or are having patches contributed.

I wrote a mpris2 dataengine [1] that implements all the core parts of
the spec (including control via services).  It's fully asynchronous (no
more freezing plasma while talking over the bus).  It doesn't require
any polling, even for track position information.  It's fully tested in
plasma engine explorer.  It doesn't have widgets yet, but I plan to port
the nowplaying widget to it (or, more likely, write a nowplaying
replacement in Plasma Quick).

The question is: what should happen with this?  I'd like it to replace
the horrible, broken mess that is nowplaying completely, ideally.
However, there are presumably things using nowplaying.  I can't really
do a compatibility layer (otherwise you losing the nice no-polling
property, and also the time units clash).

Eike Hein suggested that mpris2 should go into kde-workspace, next to
nowplaying, to allow widget authors to port away from nowplaying.  (The
trouble with putting mpris2 in addons is that there would be an
incentive - ubiquity - for widget authors to continue to use
nowplaying).  In 5.0, nowplaying can be ditched, and mpris2 can move to
addons, if that's a more sensible place for it long-term.

Thoughts?

Alex



[0]: http://www.freedesktop.org/wiki/Specifications/mpris-spec
[1]: git://anongit.kde.org:scratch/alexmerry/mpris2-dataengine