Plasma Media Center and state machines

[Shantanu Tushar Jha]

(My ideas, be free to kick ;)

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.
What I propose is not altering the libraries, but to have a state
machine for each component (component as in the containment,
controller applet etc). Though I don't have code to show that right
now (i'm writing a small Qt app to demo it), I'll try to explain a
sample working-

User chooses "Pictures", containment goes to Pictures state and emits
a signal which other components receive and decide what to do (which
will be generally changing their states too), and so they can layout
themselves (add/remove UI elements like buttons).

This way, we can just have the new plugin have its own state machine
to do its stuff. So, we get something like an independence between the
components, they just interact, there is no central manager who needs
to know everything.
Another advantage will be that we don't have to change all applets at
once for this, we can first build the containment state machine, test
it, and then commit the code (at this point some functionality will be
broken, but thats why its called playground) which helps keeping the
things in small increments and easy for the others to follow. Then we
can proceed to making the applets like controller,browser to be aware
of these changes.

Please point out if at any point I've gone wrong (or, so many
statemachines will mean lots of overhead).

Thanks,

On Fri, Apr 2, 2010 at 2:13 AM, 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.
>
>> >>     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
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



-- 
Shantanu Tushar    (UTC +0530)
http://www.shantanutushar.com