Plasma Media Center and state machines

[Alessandro Diaferia]

2010/4/4 Aaron J. Seigo <aseigo at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



-- 
Alessandro Diaferia
KDE Developer
KDE e.V. member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100405/6d678a29/attachment-0001.htm