Plasma Media Center and state machines

[Aaron J. Seigo]

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

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

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.

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