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