[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-04 23:59:08
Message-ID: s2s65627f3a1004041659l37102e95w496fa63490957754 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<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>
_______________________________________________
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