On Fri, Apr 2, 2010 at 7:31 PM, Christophe Olinger <oling...@binarylooks.com> wrote: > > > On Thu, Apr 1, 2010 at 10:43 PM, Aaron J. Seigo <ase...@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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > -- Shantanu Tushar (UTC +0530) http://www.shantanutushar.com _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel