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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
