Yeah, a meeting would be great.
I'm UTC+2 together with Marco i suppose.
My chances to be there are the highest between 7:00 AM and 16.00 PM - UTC :)
2010/4/5 Shantanu Tushar Jha <jhahon...@gmail.com>
> 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
>
--
Alessandro Diaferia
KDE Developer
KDE e.V. member
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
