Yeah, a meeting would be great.<div><br></div><div>I'm UTC+2 together with Marco i suppose.</div><div>My chances to be there are the highest between 7:00 AM and 16.00 PM - UTC :)<br><br><div class="gmail_quote">2010/4/5 Shantanu Tushar Jha <span dir="ltr"><<a href="mailto:jhahoneyk@gmail.com">jhahoneyk@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">What about having a meeting this Sunday?<br>
<div><div></div><div class="h5"><br>
On Mon, Apr 5, 2010 at 5:29 AM, Alessandro Diaferia<br>
<<a href="mailto:alediaferia@gmail.com">alediaferia@gmail.com</a>> wrote:<br>
><br>
><br>
> 2010/4/4 Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>><br>
>><br>
>> 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>
>> in my mind that translates to "should be documented on the techbase page"<br>
>> ;)<br>
><br>
> Ok right, will do as soon as things get more clear through this thread :-)<br>
>><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<br>
>> > it<br>
>> > possible to write plugins to show different kind<br>
>> > of media types providing a QAbstractItemModel.<br>
>><br>
>> 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>
><br>
> We *must* rename it! :-p That was just a quick-mind-generated name..<br>
> (WARNING: I'm still referencing to them as ModelPackage in this mail :)<br>
>><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>
>> would it make sense to allow the MediaBrowser to use DataEngines directly?<br>
>> it<br>
>> would make the code a more complex since it would have to work with either<br>
>> a<br>
>> QAbstractItemModel or a Plasma::DataEngine, but it would make writing<br>
>> plugins<br>
>> which are DataEngines much simpler.<br>
><br>
> This is an interesting point i didn't think about. We might want to directly<br>
> talk about this as MediaBrowser internally reads QAbstractItemModels to<br>
> generate the elements in the view.<br>
>><br>
>> > Both are<br>
>> > extensible themself through plugins. They're supposed to work as data<br>
>> > source for MediaBrowser models.<br>
>><br>
>> 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<br>
>> 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>
><br>
><br>
> This is just fine for me :-)<br>
>><br>
>> in any case, are there any PictureProviders yet? i see the picasa and<br>
>> flickr<br>
>> DataEngines ... but they aren't PictureProviders.<br>
><br>
><br>
> We currently have the flickr PictureProvider that is under<br>
> pictureproviders/<br>
> The picasa one is just matter of converting it from plain DataEngine to<br>
> PictureProvider and I'll do this asap.<br>
>><br>
>> going back to the UI side of this, how will all of these different sources<br>
>> of<br>
>> pictures be presented to the person using PMC? how will they enter the<br>
>> account, password, etc. that is needed?<br>
><br>
> I spent some time thinking about this. The idea was that ModelPackage API<br>
> (or whatever it is called :)<br>
> would have allowed specifying something like a passwordNeeded(const KUrl<br>
> &url) signal when a particular navigation to a restricted area (pointed by<br>
> url) is requested and setPassword(const QString &password, const KUrl &url)<br>
> to specify the credentials for a specific area (still url). Of course this<br>
> is just an example,<br>
> the real approach should be studied in detail.<br>
>><br>
>> hm.. looking further, both the flickr and picasa DataEngines are just<br>
>> wrappers<br>
>> around Interface classes that implement a query(..) method, very similar<br>
>> to<br>
>> the PictureProvider API. is the intention to turn these two DataEngines<br>
>> into<br>
>> PictureProviders?<br>
><br>
> Yep! See above :-)<br>
><br>
>><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<br>
>> the<br>
>> UI.<br>
>><br>
>> i like the idea of a single PictureProvider that provides access to data<br>
>> 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<br>
>> look<br>
>> like?<br>
><br>
> I think that ModelPackage API can have something like<br>
> Plasma::Applet::*configurationInterface*.<br>
> Each ModelPackage knows how its data source work and so how to pass to its<br>
> data source the needed bits for authentication and stuff.<br>
> Taking the particular example of the Picture DataEngine and a ModelPackage<br>
> that uses it we can have the following behaviors:<br>
> PictureModelPackage has a configuration widget that allows setting login<br>
> information for each provider of the Picture DataEngine.<br>
> Of course Picture DataEngine will have some specific query that allows<br>
> logging into a particular user profile for each provider and keep those<br>
> authentication info for every future query.<br>
> Once the login information is set up the PictureModelPackage will simply<br>
> query the Picture DataEngine.<br>
> I think that ModelPackage API should give the chance to specify whether the<br>
> particular ModelPackage plugin will require a SearchLineEdit for the media<br>
> navigation it exposes through the QAbstractItemModel. Then each query should<br>
> automatically be done for every provider available through the DataEngine.<br>
>><br>
>> * what will the query user interface look like?<br>
><br>
><br>
> A simple SearchLineEdit? Probably with some eventual advanced-search<br>
> features?<br>
>><br>
>> * should the query be a Plasma::Service? returning a list of photos?<br>
><br>
><br>
> Probably. I think this depends on how we want MediaBrowser plugins to<br>
> behave.<br>
>><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<br>
>> of<br>
>> the picture (however flickr, etc. do that) with the value being a custom<br>
>> data<br>
>> structure containing all that info (we can stuff anything we want into a<br>
>> QVariant, remember :)<br>
><br>
> Currently we have a specific data structure for the query results so i think<br>
> your second approach suggestion is what suits better :)<br>
>><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<br>
>> > 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>
>> 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<br>
>> could<br>
>> be nice. still, i wouldn't make things more complex for ourselves by<br>
>> 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>
><br>
><br>
> I really don't know about this :/<br>
>><br>
>> > The playback is then controlled by the MediaPlayer Applet and the<br>
>> > MediaController which, again, are the implementations of a public API<br>
>> > too.<br>
>><br>
>> where are these classes?<br>
><br>
> Those are just them under applets/.<br>
><br>
>><br>
>> are the pluggable as well, or are they meant to be<br>
>> used from plugins (e.g. States)?<br>
><br>
><br>
> They're the implementation of the public API and they're not pluggable.<br>
> They shouldn't be used from plugins as they're the specific implementation.<br>
> Plugins should instead interact with the libs/{playbackcontrol.h,player.h}<br>
> API likely asking the containment for the actual pointer to the<br>
> implementations loaded at the moment.<br>
>><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<br>
>> > PMC<br>
>> > components.<br>
>> > Later, together with Marco, we decided to abandon that in order to just<br>
>> > 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>
>> 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.<br>
>> this<br>
>> gives us the plugin capability for free.<br>
><br>
> Agreed :-)<br>
><br>
>><br>
>> --<br>
>> 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>
><br>
><br>
><br>
> --<br>
> Alessandro Diaferia<br>
> KDE Developer<br>
> KDE e.V. member<br>
><br>
><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>
><br>
><br>
<br>
<br>
<br>
--<br>
</div></div><div class="im">Shantanu Tushar (UTC +0530)<br>
<a href="http://www.shantanutushar.com" target="_blank">http://www.shantanutushar.com</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">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>
</div>