Plasma Media Center and state machines

[Christophe Olinger]

On Thu, Apr 1, 2010 at 10:43 PM, Aaron J. Seigo <aseigo at kde.org> wrote:

> On April 1, 2010, Christophe Olinger wrote:
> > >>     sliderMusicModeSeek;
> > >>     iconSlideshow;
> > >>     iconRotateCW;
> > >>     iconRotateCCW;
> > >
> > > would these rotation ones belong to the image browser, and be provided
> as
> > > "custom" elements rather than named elements in the main enum?
> >
> > I thought we could to this:
> > Have a main enum with things common to the states (enum
> MainSubComponents)
> > Have an enum with things specific to a state. (enum
> > BrowseVideoModeSubComponents)
> > In that case, the rotate buttons would be part of the BrowsePictureMode
> and
> > BrowseSinglePictureMode enums?
> > Custom widgets always belong to some state, don't they?
>
> yes; what i was/am unclear on in your email was how the enums were all
> mixed
> together with both the common sub-components and the state-specific ones
> listed there.
>


They will be seperated in the real implementation.
Shared widgets will be owned by the MediaCenterState class, while state
specific widgets will be owned by the state subclasses.


>
> > >>     browserGoPrevious
> > >>     playerPlayPauseVideo
> > >>     playerPlayPauseMusic
> > >>     playerPlayPausePictures
> > >
> > > what would thse signals be used for, exactly? and why are there
> separate
> >
> > ones
> >
> > > for Video, Music, Pictures, etc?
> >
> > I thought that if the controlBar needs to tell the browser to go up one
> > levelm it needs a signal to do that and the browser needs a slot to
> accept
> > that. When we handle connecting applets between them in the
> > mediacontainment or whereever, we only have the type implemenations of
> the
> > applets available. By adding public slots and signals to the type
> classes,
> > we make sure that we do not forget reimplementing these in the actual
> > applets.
>
> ah, you mean as interface descriptions for the media center applets? sure,
> that makes sense.
>

Uff


>
> > > i think the MediaCenterState object should simply remove/hide all
> >
> > components
> >
> > > that were visible in the last state but which are not visible in the
> now-
> > > current state.
> >
> > Thats why I thought keeping a list when entering a state would be a good
> > idea.
>
> yes; but not in the state subclasses. do it in the class that owns the
> shared
> widgets so that those objects are never directly exposed.
>

Ok, as above: MediaCenterState object created by containment will own shared
widgets. There will actually not be many of these I think.


>
> > When each state object adds widgets to applets, how can the
> > MediaCenterState object know about this?
>
> what widgets to which applets?
>

That was a stupid question by me. On state change, First the shared widgets
in the MediaCenterStage will be looked at and added to the applets and than
the state specific widgets will follow. At the moment, this only concerns
the ControlBar and the InfoBar applets. The player, playlist, browser all
have the same widgets in all states. Except maybe the tab bar that we want
to add to the browser.
Shared widgets are JumpToHomeScreen and the widgets showing the active
background modes. Probably toggle autohide buttons.
The HomeScreen widgets will belong to the homeState object.


>
> > Would this be done by having the list defined in the MediaCenterState
> > Object and the individual states would use that list.
>
> yes, i think so.
>
> > A simple public (or protected) member variable?
>
> avoid shared members, use accessors and setters. (encapsulation)
>

sorry, setters and getters FTW


>
> > > QList<MediaCenter::SubComponent> components =
> newState->subComponents();
> >
> > Okay, so in each State class I need a subComponents() function that
> returns
> > pointers of all subComponents needed in that state.
>
> of all the *custom* sub-components.
>

indeed


>
> > What about the general ones from the MediaCenterState class?
>
> my guess is that those are owned by the containment, and so it is the
> containment that should be managing them. the state object (subclass of
> MediaCenterState) should simply describe a layout, nothing more.
>

let's see in an actual implementation


>
> > "newState" will be replaced by the actual object that is the next stage?
>
> newState is the next state, in that example. and yes, on the next
> transition
> it would be done all over again with the new state.
>
> > > QListIterator<MediaCenter::SubComponent> it (m_visibleSubComponents);
> >
> > The m_VisibleSubComponents was filled on state change by the last state
> and
> > is stored in the MediaCeterState object?
>
> no, probably in the containment. there will be multiple MediaCenterState
> objects (one for each state in the machine), but only one set of
> components,
> owned by the containment.
>

true. very true.


>
> > > while (it.hasNext()) {
> > >
> > >   MediaCenter::SubComponent c = it.next();
> > >   if (!components.contains(c)) {
>
> small bug: this sould be:
>
> if (c >= MediaCenter::CustomSubComponent || !components.contains(c))
>
> all custom components should be removed.
>
> > >
> > >       MediaCenterComponent *w = m_subComponents.value(c);
> > >
> > >        if (w) {
> > >
> > >             w->hide(); // TODO animate
>
> anothe bug: w also needs to be removed from the layout.
>
> probably time to start drafting some class headers and putt them into svn
> so
> we can work together from there :)
>


Okay. Everything seems clear now for me. I'll start coding (all the above
were just code snippets in a document) Just the last thing that Shan
suggested:

Currently, I thought of having state objects (one main, many sub) that are
handled my the containment and that can send widgets to the applets and tell
the applets what to do. The state objects would iterate over all applets.
Extending PMC would mean just adding a new state object type which would
include instructions for all applets. Also a button would need to be added
to the homeScreenState.

Shan proposed to have states for each applet. I my mind this means that a
plugin would need to write states for all applets, so actually similar to
the above, except that the instructions are closer to the applets and
seperated in individual state objects. Sounds more complicated to extend in
my head.

(Of course the states should not be confused by datanegines and model/view
stuff, although the states initiate different model/views for the browser
for example)

What do you think?

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100402/4efebecf/attachment-0001.htm