<br><br><div class="gmail_quote">2008/7/14 Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
in the plugin scenario, you should be using KDE's plugin system (built on top<br>
of Qt's plugin system) which is documented in tutorials on techbase, iirc.<br>
<br>
to give you more specific suggestions, if you could provide the API of the<br>
generic class or at enumerate the funtionality the class would provide then i<br>
might be able to suggest some things.<br>
<br>
(what would be beautiful is if all the media players had a consistent d-bus<br>
interface, but i daren't dream that far ;)<br></blockquote></div><br>Well, I did make a spreadsheet laying out the capabilities likely required and the DBus bindings on different media players that match. But since it's basically an enhanced now playing plasmoid, all that's really needed is a system to get the metadata from the currently playing file (which could likely be done even if all DBus returns is a file address), and of course the usual playing controls (play, stop, pause, next, prev). I was also thinking about allowing the album image for players like Amarok that provide it, but that would have to be optional since it's not always provided (though a lot of players do offer necessary access to it).<br>
<br>In fact, the main reason I started to think about using a plugin system was because I noticed that the media players have varying DBus implementatons. Originally, I was just going to have an XML file that contained the info in the spreadsheet for each media player, and then use that to get the data I wanted, but I started to have second thoughts when I noticed that the DBus bindings were majorly variant. I'm leaining towards the plugin artitecture now because then I can encapsulate not only the DBus binding differences, but the differences in things like return values and such that the various DBus bindings send back (as a great example, some of the players send back the album cover as encrypted image data, and some send an URL to the image file; that would be a good place to encapsulate the handling so that either way, the plugin user sees the same result).<br>
<br>I imagine it's obvious here, but what I'm trying to do is design an applet that can be easily added to, so that we don't end up in the situation we have been in before (where there are multiple different now playing applets because each one supported different media players).<br>