<br><br><div class="gmail_quote">On Thu, Apr 1, 2010 at 10:43 PM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On April 1, 2010, Christophe Olinger wrote:<br>
> >> sliderMusicModeSeek;<br>
> >> iconSlideshow;<br>
> >> iconRotateCW;<br>
> >> iconRotateCCW;<br>
> ><br>
> > would these rotation ones belong to the image browser, and be provided as<br>
> > "custom" elements rather than named elements in the main enum?<br>
><br>
> I thought we could to this:<br>
> Have a main enum with things common to the states (enum MainSubComponents)<br>
> Have an enum with things specific to a state. (enum<br>
> BrowseVideoModeSubComponents)<br>
> In that case, the rotate buttons would be part of the BrowsePictureMode and<br>
> BrowseSinglePictureMode enums?<br>
> Custom widgets always belong to some state, don't they?<br>
<br>
</div>yes; what i was/am unclear on in your email was how the enums were all mixed<br>
together with both the common sub-components and the state-specific ones<br>
listed there.<br></blockquote><div><br><br>They will be seperated in the real implementation.<br>Shared widgets will be owned by the MediaCenterState class, while state specific widgets will be owned by the state subclasses.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> >> browserGoPrevious<br>
> >> playerPlayPauseVideo<br>
> >> playerPlayPauseMusic<br>
> >> playerPlayPausePictures<br>
> ><br>
> > what would thse signals be used for, exactly? and why are there separate<br>
><br>
> ones<br>
><br>
> > for Video, Music, Pictures, etc?<br>
><br>
> I thought that if the controlBar needs to tell the browser to go up one<br>
> levelm it needs a signal to do that and the browser needs a slot to accept<br>
> that. When we handle connecting applets between them in the<br>
> mediacontainment or whereever, we only have the type implemenations of the<br>
> applets available. By adding public slots and signals to the type classes,<br>
> we make sure that we do not forget reimplementing these in the actual<br>
> applets.<br>
<br>
</div>ah, you mean as interface descriptions for the media center applets? sure,<br>
that makes sense.<br></blockquote><div><br>Uff<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> > i think the MediaCenterState object should simply remove/hide all<br>
><br>
> components<br>
><br>
> > that were visible in the last state but which are not visible in the now-<br>
> > current state.<br>
><br>
> Thats why I thought keeping a list when entering a state would be a good<br>
> idea.<br>
<br>
</div>yes; but not in the state subclasses. do it in the class that owns the shared<br>
widgets so that those objects are never directly exposed.<br></blockquote><div><br>Ok, as above: MediaCenterState object created by containment will own shared widgets. There will actually not be many of these I think.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> When each state object adds widgets to applets, how can the<br>
> MediaCenterState object know about this?<br>
<br>
</div>what widgets to which applets?<br></blockquote><div><br>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.<br>
Shared widgets are JumpToHomeScreen and the widgets showing the active background modes. Probably toggle autohide buttons.<br>The HomeScreen widgets will belong to the homeState object.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> Would this be done by having the list defined in the MediaCenterState<br>
> Object and the individual states would use that list.<br>
<br>
</div>yes, i think so.<br>
<div class="im"><br>
> A simple public (or protected) member variable?<br>
<br>
</div>avoid shared members, use accessors and setters. (encapsulation)<br></blockquote><div><br>sorry, setters and getters FTW<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> > QList<MediaCenter::SubComponent> components = newState->subComponents();<br>
><br>
> Okay, so in each State class I need a subComponents() function that returns<br>
> pointers of all subComponents needed in that state.<br>
<br>
</div>of all the *custom* sub-components.<br></blockquote><div><br>indeed<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> What about the general ones from the MediaCenterState class?<br>
<br>
</div>my guess is that those are owned by the containment, and so it is the<br>
containment that should be managing them. the state object (subclass of<br>
MediaCenterState) should simply describe a layout, nothing more.<br></blockquote><div><br>let's see in an actual implementation<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> "newState" will be replaced by the actual object that is the next stage?<br>
<br>
</div>newState is the next state, in that example. and yes, on the next transition<br>
it would be done all over again with the new state.<br>
<div class="im"><br>
> > QListIterator<MediaCenter::SubComponent> it (m_visibleSubComponents);<br>
><br>
> The m_VisibleSubComponents was filled on state change by the last state and<br>
> is stored in the MediaCeterState object?<br>
<br>
</div>no, probably in the containment. there will be multiple MediaCenterState<br>
objects (one for each state in the machine), but only one set of components,<br>
owned by the containment.<br></blockquote><div><br>true. very true.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> > while (it.hasNext()) {<br>
> ><br>
> > MediaCenter::SubComponent c = it.next();<br>
> > if (!components.contains(c)) {<br>
<br>
</div>small bug: this sould be:<br>
<br>
if (c >= MediaCenter::CustomSubComponent || !components.contains(c))<br>
<br>
all custom components should be removed.<br>
<div class="im"><br>
> ><br>
> > MediaCenterComponent *w = m_subComponents.value(c);<br>
> ><br>
> > if (w) {<br>
> ><br>
> > w->hide(); // TODO animate<br>
<br>
</div>anothe bug: w also needs to be removed from the layout.<br>
<br>
probably time to start drafting some class headers and putt them into svn so<br>
we can work together from there :)<br></blockquote><div><br><br>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:<br>
<br>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.<br>
<br>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.<br>
<br>(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)<br><br>What do you think?<br><br>Chris<br></div></div><br>