<br><br><div class="gmail_quote">2010/4/4 Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On April 4, 2010, Alessandro Diaferia wrote:<br>
> > e.g. add an entry to the playlist.<br>
> ><br>
> > so this means we need to define some concrete APIs for playlist<br>
> > interaction,<br>
> > media browser population (both of categories and entries).<br>
><br>
> This part is a bit convoluted.<br>
<br>
</div>in my mind that translates to "should be documented on the techbase page" ;)<br></blockquote><div><br></div><div>Ok right, will do as soon as things get more clear through this thread :-) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> We currently have an API for MCApplets<br>
> themself. The particular implementation<br>
> of the MediaBrowser Applet has, itself, its own plugin system that makes it<br>
> possible to write plugins to show different kind<br>
> of media types providing a QAbstractItemModel.<br>
<br>
</div>this is the ModelPackage class?<br>
<br>
can we rename that for clarity? e.g. MediaListModel? MediaBrowserModel?<br>
<br>
mc_modelpackage.desktop should also be renamed in the process; plasma-<br>
mediacenter-mediabrowsermodel.desktop for instance :)<br></blockquote><div><br></div><div>We *must* rename it! :-p That was just a quick-mind-generated name.. (WARNING: I'm still referencing to them as ModelPackage in this mail :)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> The way data is fetched is<br>
> completely transparent to the Applet but it is<br>
> suggested to make use of the DataEngines PMC already provides. Such<br>
> DataEngines are there and they're Video DataEngine and<br>
> Picture DataEngine (both written together with the Silk team).<br>
<br>
</div>would it make sense to allow the MediaBrowser to use DataEngines directly? it<br>
would make the code a more complex since it would have to work with either a<br>
QAbstractItemModel or a Plasma::DataEngine, but it would make writing plugins<br>
which are DataEngines much simpler.<br></blockquote><div><br></div><div>This is an interesting point i didn't think about. We might want to directly talk about this as MediaBrowser internally reads QAbstractItemModels to generate the elements in the view.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Both are<br>
> extensible themself through plugins. They're supposed to work as data<br>
> source for MediaBrowser models.<br>
<br>
</div>going through the code, i see that the term "Package" is much loved.<br>
unfortunately, we already have a meaning for "Package" in libplasma, and it's<br>
not at all what the various Package classes and structs are. would it be<br>
possible to rename those classes to something doesn't use Package? e.g.<br>
"PictureDescription"<br></blockquote><div> </div><div>This is just fine for me :-) </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
in any case, are there any PictureProviders yet? i see the picasa and flickr<br>
DataEngines ... but they aren't PictureProviders.<br></blockquote><div> </div><div>We currently have the flickr PictureProvider that is under pictureproviders/ </div><div>The picasa one is just matter of converting it from plain DataEngine to PictureProvider and I'll do this asap.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
going back to the UI side of this, how will all of these different sources of<br>
pictures be presented to the person using PMC? how will they enter the<br>
account, password, etc. that is needed?<br></blockquote><div><br></div><div>I spent some time thinking about this. The idea was that ModelPackage API (or whatever it is called :)</div><div>would have allowed specifying something like a passwordNeeded(const KUrl &url) signal when a particular navigation to a restricted area (pointed by url) is requested and setPassword(const QString &password, const KUrl &url) to specify the credentials for a specific area (still url). Of course this is just an example,</div>
<div>the real approach should be studied in detail.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
hm.. looking further, both the flickr and picasa DataEngines are just wrappers<br>
around Interface classes that implement a query(..) method, very similar to<br>
the PictureProvider API. is the intention to turn these two DataEngines into<br>
PictureProviders?<br></blockquote><div><br></div><div>Yep! See above :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
it's all a bit confusing in there at the moment due to the various bits of<br>
seeming duplication, and i don't see how this is going to be exposed in the<br>
UI.<br>
<br>
i like the idea of a single PictureProvider that provides access to data that<br>
represents "pictures". the details need to be filled in though:<br>
<br>
* what will the UI to select which picasa, flickr, etc. account to use look<br>
like?<br></blockquote><div><br></div><div>I think that ModelPackage API can have something like Plasma::Applet::*configurationInterface*.</div><div>Each ModelPackage knows how its data source work and so how to pass to its data source the needed bits for authentication and stuff.</div>
<div>Taking the particular example of the Picture DataEngine and a ModelPackage that uses it we can have the following behaviors:</div><div>PictureModelPackage has a configuration widget that allows setting login information for each provider of the Picture DataEngine.</div>
<div>Of course Picture DataEngine will have some specific query that allows logging into a particular user profile for each provider and keep those authentication info for every future query.</div><div>Once the login information is set up the PictureModelPackage will simply query the Picture DataEngine.</div>
<div>I think that ModelPackage API should give the chance to specify whether the particular ModelPackage plugin will require a SearchLineEdit for the media navigation it exposes through the QAbstractItemModel. Then each query should automatically be done for every provider available through the DataEngine.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
* what will the query user interface look like?<br></blockquote><div> </div><div> A simple SearchLineEdit? Probably with some eventual advanced-search features?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
* should the query be a Plasma::Service? returning a list of photos?<br></blockquote><div> </div><div>Probably. I think this depends on how we want MediaBrowser plugins to behave. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
* should the picture information be a separate data source, or should each<br>
album/query contain a list of pictures in them, with the key being the uid of<br>
the picture (however flickr, etc. do that) with the value being a custom data<br>
structure containing all that info (we can stuff anything we want into a<br>
QVariant, remember :)<br></blockquote><div><br></div><div>Currently we have a specific data structure for the query results so i think your second approach suggestion is what suits better :)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> The playlist stuff, together with the ability to make the general state<br>
> able to control the playback is another matter we need to talk deeper<br>
> about. We have, again, an API that defines how Playlist Applet should be<br>
> implemented, and, of course, we have the PMC implementation. This<br>
> implementation makes<br>
> use of the Playlist dataengine that was meant to be a shared component for<br>
> every multimedia-application within KDE.<br>
> This way an Amarok user could fill-in his playlists and find them there<br>
> when he launches his PMC. And vice-versa of course.<br>
<br>
</div>hm; don't we already have a data interchange format for playlists? M3U or<br>
whatever? i don't think the DataEngine needs to be shared, though that could<br>
be nice. still, i wouldn't make things more complex for ourselves by making a<br>
DataEngine that will work for Amarok be a design requirement.<br>
<br>
for that matter, how does Amarok currently store its playlists? juk?<br></blockquote><div> </div><div>I really don't know about this :/ </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> The playback is then controlled by the MediaPlayer Applet and the<br>
> MediaController which, again, are the implementations of a public API too.<br>
<br>
</div>where are these classes?</blockquote><div>Those are just them under applets/. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">are the pluggable as well, or are they meant to be<br>
used from plugins (e.g. States)?<br></blockquote><div> </div><div>They're the implementation of the public API and they're not pluggable.</div><div>They shouldn't be used from plugins as they're the specific implementation.</div>
<div>Plugins should instead interact with the libs/{playbackcontrol.h,player.h} API likely asking the containment for the actual pointer to the implementations loaded at the moment.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I, originally, was working on a thing similar to a Phonon::MediaObject<br>
> wrapper that would have allowed us to expose the playback to the whole PMC<br>
> components.<br>
> Later, together with Marco, we decided to abandon that in order to just put<br>
> the playback control inside the API.<br>
><br>
> Do you think it is the case to resume that work and make it available to<br>
> the states implementations?<br>
<br>
</div>no, i don't think that is needed. we can write Plasma::Applets specific to<br>
each type of media we wish to show, and the States can reference those. this<br>
gives us the plugin capability for free.<br></blockquote><div><br></div><div>Agreed :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Development Frameworks<br>
_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alessandro Diaferia<br>KDE Developer<br>KDE e.V. member<br><br>