Plasma Media Center and state machines

Sun Apr 4 10:05:22 CEST 2010

2010/4/3 Aaron J. Seigo <aseigo at kde.org>

> On April 1, 2010, Shantanu Tushar Jha wrote:
> > Hi Christophe, now I'm able to understand most of what you've
> > proposed. Somehow, I don't like having just one state machine for the
> > whole MC, the main reason being that we're going to support
> > extensibility through custom plugins, so the MC can no longer assume
> > that it knows exactly how many states are present.
>
> there are two different things here:
>
> * how the states are created / registered
>
> * how the states interact with the user interface
>
> they are separate issues: regardless of how they interact with the UI, they
> can be created statically using a hard coded list of "new ThisState; new
> ThatState;" type calls, by iterating over a static set of enums or
> completely
> through plugins.
>
> the key here is that each top level mode (e.g. each item that appears on
> the
> home page) will be a top level state.
>
> that means that "the MC can no longer assume it knows exactly how many
> states
> are present" is completely and wholy irrelevant to the topic of "should we
> use
> a state machine".
>
> where "we want plugins" does matter is when it comes to "how do they
> interact
> with the user interface".
>
> let's try to lay down some axioms so we can discuss this fruifully:
>
> * there will be a shared home page
>
> * there will be a set of shared / common components available, such as the
> playlist, media browser and control bar
>
> * there will be some set of shared / common sub-components, such as a
> global
> pause button in the control bar
>
> * a state may also need to provide custom sub-components
>
> * a state may also want to provide a custom component for the main viewing
> area (e.g. a full screen plasmoid for weather, or a special browsing
> widget)
>
> if we can agree on those points, then we can ask: how can plugins work?
>
> well, it becomes evident that we should provide a way to define which
> common
> components and sub-components are useful in a given context from a state.
>
> we also need to allow states to register custom sub-components and provide
> a
> "main viewing area" component as well. (additional components that live on
> screen edges, augment the home page, etc. can be something we think about
> later once we have something releasable in hand today).
>

Probably I've never said it clearly but i think that we *should* use plugins
for the PMC states.
The thing is, exactly, defining a way to make shared components accessible
by everyone and sub-components
exported to the PMC. I don't think this is too difficult to do and, anyway,
we can just decide a day for a meeting on IRC
in order to put down some ideas about a possible API for MCStates plugins.

> a state should be able to enumerate child states as well. this will allow
> the
> home page entries to list all the things you can do, for instance, with
> "Photos" (browse, slideshow, add, whatever) if we so wish (see how the PS3,
> XBox 360 or moovida displays sub-menus on main entries)
>

a state will need to be able to interact with the shared components as well,
> 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. 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. 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). Both are
extensible themself through plugins. They're supposed to work as data source
for MediaBrowser models.

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.

The playback is then controlled by the MediaPlayer Applet and the
MediaController which, again, are the implementations of a public API too.

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?

>
> note that all of the above is true regardless of whether we use a state
> machine to drive the whole thing or not.
>
> what the state machine gets us is a way to do the above in a modular
> fashion
> without writing all of the state machine boilerplate ourselves. if we
> really
> want (and if it is more undertandable for everyone involved) we could just
> as
> easily write the plugins in a more "traditional" fashion. we'll still end
> up
> with a state machine for all intents and purposes because the modes are
> mutually exclusive and full screen.

> the only exception to all of this is the playing of individual media. that
> is
> yet another topic, however. the above is all about the navigation and
> control
> UI which must work together seemlessly (visually and interation wise). how
> a
> mode (plugin or not) provides media playing is another matter (and
> personally
> i'm leaning towards providing a shared mechanism for that which is in PMC
> itself, so a state / plugin can just say "start playing this video" or
> "start
> playing this set of images"), just as the media browser should provide.
>

Agreed and this is related to what i wrote above.

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

Regards

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