Plugins: Use Qt plugin art. or XML?

[Kelly Miller]

2008/7/14 Aaron J. Seigo <aseigo at kde.org>:

> in the plugin scenario, you should be using KDE's plugin system (built on
> top
> of Qt's plugin system) which is documented in tutorials on techbase, iirc.
>
> to give you more specific suggestions, if you could provide the API of the
> generic class or at enumerate the funtionality the class would provide then
> i
> might be able to suggest some things.
>
> (what would be beautiful is if all the media players had a consistent d-bus
> interface, but i daren't dream that far ;)
>

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).

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).

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080714/7885264d/attachment.html