Plasma Media Center and state machines

[Aaron J. Seigo]

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.

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

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

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

what widgets to which applets?

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

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

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

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

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