Plasma Media Center and state machines

[Aaron J. Seigo]

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" ;)

> 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 :)

> 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.

> 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"

in any case, are there any PictureProviders yet? i see the picasa and flickr 
DataEngines ... but they aren't PictureProviders.

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?

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?

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?

* what will the query user interface look like?

* should the query be a Plasma::Service? returning a list of photos?

* 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 :)

> 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?
 
> 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? are the pluggable as well, or are they meant to be 
used from plugins (e.g. States)?
 
> 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.

-- 
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