I’ve just finished writing a tester app for MPRIS. It covers all the parts of the standard for querying and controlling media players over D-Bus.
It’s pure Qt, since I didn’t need any KDE-specific stuff – it’s just a quick hack, anyway.
I was going to write it in (and use it to learn) a scripted language like python, but I got impatient. I might reimplement it in an interpreted language at some point.
There are a couple of problems (to do with receiving structs of ints) that I need to track down to either my program or Amarok (or both – I reference Amarok’s code when implementing those bits). But other than getting the status and the MPRIS version, it seems to work. And I think it’ll be a handy little tool.
I’ll upload it to Qt-Apps.org when that site returns to normality, but in the meantime:
Edit: The application can be found at Qt-Apps.

20th July 2008 at 9:42 pm |
Linky linky…
After Cornelius blogged his bit on using Wordle, I made my own of my blog, and it’s clear that there’s one topic I mention far too often; also the distinction between KDE and KDE4 isn’t clear to the Wordle software. And “stuff” is in there along w…
21st July 2008 at 7:10 am |
Could you explain what MPRIS actually is?
I am new to KDE and QT so although this acronym might seem trivial for you, it is not for all your readers.
I suppose it’s some kind of protocol or library used in KDE. I read your post since I am interested in automatic testing and applications that help doing automatic regression testing.
21st July 2008 at 9:41 am |
I wonder which of the interpretation variants you used to implement the MPRIS spec.
Do you ignore the name of the interface and just fake the same one despite each object having a different one?
Or do you just send all calls to one of the objects, since it implements all methods anyway?
21st July 2008 at 7:26 pm |
@Bogdan: Oops, I should have linked to that. Done now, in both posts.
@Kevin: I implemented it the way the spec defines it: using the same interface name for three different interfaces. It’s daft, but there you go.
21st July 2008 at 11:10 pm |
Well, the spec leave several interpretations open, e.g. what does a service reply to one of the interface’s method described for one object when being called on another.
Of course this is easier for the client side since it can avoid calls to underdefined methods, but a service implementation will have to be tested against all clients it cares about and should probably implement fallback behavior for those it can’t be tested against.
It unfortunately also breaks discoverability, i.e. letting power users find ways to interact through testing calls (one of the very successful properties of DCOP).
Finding out through trial&error why three object have the same interface but are picky about which method is called where, for probably more than one service implementation they care about, will make this quite frustrating.
I guess that at least for the KDE users among them their programs will also have a sane interface, like their KDE3 versions had with DCOP.
6th August 2008 at 12:46 pm |
[...] Confused? Read my introductory post about MPRIS Tester. [...]
11th August 2008 at 2:51 pm |
[...] You can download it at Qt-Apps.org, and you can find out more about MPRIS Tester from an older post. [...]
12th August 2008 at 3:36 pm |
I found your site on technorati and read a few of your other posts. Keep up the good work. I just added your RSS feed to my Google News Reader. Looking forward to reading more from you down the road!