Review Request: State machine architecture for PMC

[Christophe Olinger]

>
> I like the idea of the state machine and how it could help us correctly
> managing the workflow of the mediacenter. Unfortunately i feel something in
> the current implementation lacks of robustness (does this word exist?).
>
> As Aaron pointed out, we need to understend whether we are aproaching this
> the right way.
>
> The mistake with the MediaLayout in this patch well shows that we should
> probably re-design something. The need for states is due to the fact that we
> want PMC to know the current media in order to differently behave and
> interact with the user. This way we could give the best set of actions for
> each kind of media chosen by the user.
> The first clear issue was the lack for a way of changing the UI accordingly
> to the chosen media.
>

Here is a list of the issues we need to tackle correctly and agree on where
to do it
Things that change on a state switch:

* The applets (called UIComponents) get a new set of widgets. Some widgets
are always the same. These I called MainSubComponents and are only added
once at PMC initialization. Others change with each state, these are
shown/hidden on each state switch.
->adding MainSubcomponents is currently handled by the MediaCenterState
class, adding subcomponents is handled by the different state classes.

*The MainSubComponents and SubComponents are connected to public
slots/signals of the applets.
->This happens only once at PMC initialization, either by the
MediaCenterState class, or the state classes themselves

*The MainSubComponents and SubCompomnents are connected to slots of the
medialyout. This is needed to handle toggling autohides and things like
that. This is only done at PMC initialization
->again tis is handled by the MediaCenterState class for MainSubComponents
or the state classes themselves for SubComponents.

*On each state switch the UIComponents get told to switch configuration,
like show/hide, or load a ceratin dataengine for the mediabrowser, maybe
load a playlist setting,...
->This is handled by the state object classes themselves

*On each state switch the layout needs to put the UIComponents in to a
certain state, like show playlist by default in music state,...
-> handled by the state classes

All this is handled by the state classes, but initiated by the containment
which hands out pointers of the medialayout, or the UIComponents. The
advantage of this is that we have all configuration stuff collected in one
place, namely the state classes. We just need the containment to be able to
find all state classes and iterate over them. Extending PMC would just mean
adding a new state class.

A question is where do we handle the animations? In the state classes, or
the containment?

One thing missing is the layout of the actual subComponents in the applets.
Currently they are just added in a row. For this we need the API. The layout
should recognize which type of applet arrives and lay it out accordingly.
That means lots of if/thens within tha applet code. This also means adding
new states with new subcomponents would mean adding if/tehns to the actual
addToLayout functions in the applets.


>
> I'd go with questions here in order to better summarize what we need in the
> PMC:
>
> Q1. When do we need the UI to react to media type changes?
> R1. The UI should show different possible actions to the user both while
> browsing to a personal collection of e.g. videos and when actually
> reproducing a video.
>

Agreed. This will mean having parent states (Music, Picture, Vide) but also
Child states for each (browsing, sllideshow, playing,...)


>
> Q2. How the PMC knows which kind of media are we browsing
> through/reproducing ?
> R2. The PMC::Browser API should be updated in order to expose this kind of
> information. In addition to this the PMC::Player should be used in order to
> retrieve this kind of information while reproducing media.
>

We can also control this oursleves. On state switch, the browser will only
be able to change those media types allowed in that state, by setting the
mediabrowser to the correct dataengine. So we actually do not need to act on
the selected mediatype, because we can be sure that only one type is visible
to the user. Does this sound too crazy?


>
> Q3. Are media types mutually exclusive?
> R3. This (unfortunately?) cannot always be true. The user might want to
> start his favourite playlist and then run a slideshow of his summer photos.
> Probably the PMC::Player should inform whether music is currently playing in
> background. I'd like to know from you whether you think music is the only
> media type that can be played  in background while reproducing something
> else in foreground. This is an important topic IMHO.
>

The way I see it, we will allow states to remain in the background if they
are paused, or playing. This does not interfere with the mutual exclusivity
of media types, because the player can play some music, but still the UI can
be in a picture state. It's only the player that needs to be able to have
more than one instance active, one plays music in the background, the other
displays pictures. If I want to go back to my music, I need to go the the
music state again, so actually away from the videostate. The UI adapts
accrodingly, but the videostate is still active in the background. I hope I
expressed myself clearly in some way.
So only the player needs to know if he is in the background or not. I
imagine small icons next to the home icon that are only there if a player
instance is currently havinig some media active but is not shown. Clicking
on that icon would switch to the accroding state.


>
> Q4. Which UI controls does the PMC need?
> R4. The PMC needs of course playback controls for the current media. In
> addition to this the browser should allow the user to navigate through his
> collection of medias and eventually get back to the welcome page. The
> welcome page should IMO be inside the browser.
>

Agreed. The welcome page should be the browser showing all possible
dataengines grouped by media type. In this state, all other aplplets are
hidden. What about current active/background states. Maybe the control bar
can go into autohide mode and only show the latter.

I think that once we agree on where things are handled we can start hacking
on the details again. I feel that more or less we want the same things but
are not really sure how to get them. In that regard I would like to express
that I will be happy if you take my code and turn it upside down completely
to get it to do what we want, or rip it out again. This is all a nice ride
for me and I will not feel turned down or something if you thing my coding
is bad, or my way of seeing the redesign is.

Please test abit the current way of doing things before seeing it as too
complex.


Cheers

Chris

>
>
>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100408/37f98bed/attachment-0001.htm