[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Plugins: Use Qt plugin art. or XML?
From:       "Kelly Miller" <lightsolphoenix () gmail ! com>
Date:       2008-07-14 17:37:16
Message-ID: a785db460807141037g39d6233cjbcee1abbe0e32d26 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


2008/7/14 Aaron J. Seigo <aseigo@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).

[Attachment #5 (text/html)]

<br><br><div class="gmail_quote">2008/7/14 Aaron J. Seigo &lt;<a \
href="mailto:aseigo@kde.org">aseigo@kde.org</a>&gt;:<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&#39;s \
plugin system (built on top<br> of Qt&#39;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&#39;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.&nbsp; But since it&#39;s basically an enhanced \
now playing plasmoid, all that&#39;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).&nbsp; 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&#39;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.&nbsp; 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.&nbsp; \
I&#39;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&#39;s obvious \
here, but what I&#39;m trying to do is design an applet that can be easily added to, \
so that we don&#39;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>



_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel


[prev in list] [next in list] [prev in thread] [next in thread]