Plasma Media Center and state machines

[Shantanu Tushar Jha]

On Fri, Apr 2, 2010 at 7:31 PM, Christophe Olinger
<olingerc at binarylooks.com> wrote:
>
>
> 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.

Hehe, just because I like simplicity doesn't mean I'm always right. I
noted Marco's comment that even this doesn't solve the problem. /me
thinks, If I get an idea, I'll post.

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