[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Plasma Media Center and state machines
From: Alessandro Diaferia <alediaferia () gmail ! com>
Date: 2010-04-05 20:02:25
Message-ID: q2p65627f3a1004051302sd74cf195g86d20b0548e2461f () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <jhahoneyk@gmail.com>
> What about having a meeting this Sunday?
>
> On Mon, Apr 5, 2010 at 5:29 AM, Alessandro Diaferia
> <alediaferia@gmail.com> wrote:
> >
> >
> > 2010/4/4 Aaron J. Seigo <aseigo@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
[Attachment #5 (text/html)]
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>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic