No subject

> //This class knows about things that are important for every toplevel
> thing needed in the MediaCenter like
>  MediaType for example
>
> enum State {
>     BrowseVideos;
>     PlayVideos;
>     PlayMusic;
>     MusicVisualizations;
>     BrowsePictures;
>     SinglePictures;
>     PicturesSlideshow;
> }

is this enum really needed? it's really only something the state machine needs
to know about.

the only thing that needs to get at this would be the Home Page (or whatever
it's being called :), but if that was also part of the state machine system
then the states could quite easily just add themselves to the home page.

> //Not sure if we need this enum
> enum playbackState {
>     Playing;
>     Paused;
>     Stopped;
> }

maybe just playing/paused as a global setting. this is probably separate from
the state machine work, however.

> Important: The main MediaCenter lib knwos which types of UIComponents
> exist. If we add a new type, it needs to be included here

correct..

> ________________________________________________
>
> ***MediaCenterState (subclass of QAbstractState)***
>
> //This class allows for the MediaCenter to have states. In here we
> have only things that are needed for the containment to do its work.
> It also hands out pointers to widgets
> //It also keeps a collection of all subComponents needed within all
> states (maybe each state should keep its own subcomponents instead)
> // the problem would be that if we change between states that have the
> same subComponents, we would delete and recreate them?)
>
>
> #include "mediacenter.h"
> #include "mediacenter_export.h"
>
> namespace MediaCenter
> {
>
> enum subComponent {
>     iconVideoMode;

small detail: the first letter should be capitalized as well. also, instead of
pepending "icon", "slider", etc. i'd recommend just stating what it does.
"JumpToVideoMode", "MusicModeVolume". that way if we switch the actual UI
elements that accomplish these tasks, we don't end up with odd / outdated
enums :)

>     iconMusciMode;
>     iconPictureMode;
>     iconHomeScreen;
>     iconTogglePlaylistAutohide;
>     iconToggleControlBarAutohide;
>     iconToggleInfoBarAutohide;
>     iconVideoModePlayPause;
>     iconVideoModeSkipForward;
>     iconVideoModeSkipBackward;
>     iconVideoModeStop;
>     iconMusicModePlayPause;
>     iconMusicModeSkipForward;
>     iconMusicModeSkipBackward;
>     iconMusicModeStop;
>     sliderMusicModeVolume;
>     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?

> //here we handle the pointers of the created objects (the enum,
> initialilzation and pointer handling could be in the actual subclass
> of the state objects? makes it easier to add modes/plugins?)
>
> QGraphicsWidget
> *BrowseVideoState::giveComponent(MediaCenter::subComponent component)

should probably be createComponent(..) or just component(..)

> {
>    if (component == iconVideoMode) {
>
>        m_videoModeWidget->setIcon("bla");
>
>        return m_videoModeWidget;
>    }
> }

this is probably a bad example; the standard items such as JumpToVideoMode
should be provided by the base class. it will be shared by all modes, after
all. only custom items specific to the state should be here. for instance, the
VideoState might offer (as a made up example) a channel listing display and a
button for that should appear in the top bar. in this case, that buton would
be provided by VideoState as a custom item.

> }//ending namesapce MediaCenter
>
> __________________________________
>
> ***PlaybackControl (=ControlBar)***
> //This class defines what an actual implementation of a controlbar
> needs to be able to do
>
> //When adding a subComponent we need to return it. This is necessary
> to keep a track of them in a list in the state object
> MediaCenter::subComponent addSubComponent(MediaCenter::SubComponent)
> {
> }
>
> //This class gets the exact pointers of who do remove in a list
> void
> removeSubComponents(MediaCenter::SubComponent(QList<MediaCenter::SubCompon
> ents>) {
> }



> //these are all empty classes
>
> Important: The correct public slots and signals need to exist and
> reimplememted in the actual applet.
>
> signals
>     browserGoPrevious
>     playerPlayPauseVideo
>     playerPlayPauseMusic
>     playerPlayPausePictures

what would thse signals be used for, exactly? and why are there separate ones
for Video, Music, Pictures, etc?
- Show quoted text -
why is a subComponentList needed? should the definition of which components to
show be done in the constructor instead, and only action taken to reflect that
in the actual UI done in the enter event? if there are multiple possible
states for a mode, then those could be child states, which would make it such
that each state object would represent one configuration of widgets which
wouldn't change within that state object.

> subComponentsList <<
> addSubComponent(MediaCenterState::giveComponent(MediaCenter::iconPictureMod
> e)); ...//add all widgets
>             configure UIComponent (show, hide, autohide,...)
>         }
>         if UIComponent = "InfolBar" {
>             ...//add widgets
>         }
>         ...//treat all UIComponents
>     }
> }

> void BrowseVideoState::exit() {
>     For each UIComponent in list {
>         if (UIComponent == "ControlBar") {
>             UIComponent->removeSubComponents(subComponentsList);
>         }
>     }
> }

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.

iow, if we have the current state and it's list of components (set up using
addComponent or whatever), and a mapping between each UI element (e.g. a
button) and the corresponding component enum, then the code can iterate over
each item and check to see if it should be shown. sth like this:

QList<MediaCenter::SubComponent> components = newState->subComponents();
QListIterator<MediaCenter::SubComponent> it (m_visibleSubComponents);

while (it.hasNext()) {
   MediaCenter::SubComponent c = it.next();
   if (!components.contains(c)) {
       MediaCenterComponent *w = m_subComponents.value(c);
        if (w) {
             w->hide(); // TODO animate
         }
   }
}

m_visibleSubComponents = components;
it = m_visibleSubComponents;
int index = 0;
while (it.hasNext()) {
   MediaCenter::SubComponent c = it.next();
   MediaCenterComponent *w = m_subComponents.value(c);
   if (!w && c > MediaCenter::CustomComponent) {
        w = newState->customComponent(c);
   }

   if (w) {
        // insert into the layout appropriately
   }
}

> applets//
> _________________________________________
>
> ***MediaController class (or any other applet implementation)***
>
> controller will be told to add a widget, how this is done is its own
> problem and needs to be implememnted in the actual applet of type
> playbackcontrol.
> also the alignement and stuff
>
> reimplement addSunComponent (with return of subComponent
>
> we need to connect signal clicked() stuff to the external signals,
> how? can we be sure that all widgets will arrive. I guess yes.
> we need to get the pointers of the actual widgets.
>
>
> MediaCenter::subComponent addSubComponent(MediaCenter::SubComponent)
> {
> create layout
> add subComponent
> show subComponent
> }
>
> void removeSubComponents(QList<MediaCenter::SubComponents>)
> {
> for each subComponent
> hide subcomponent
> remove them from layout
> }

again, i don't think an explicit remove is needed. just switch between states,
where each state defines all the SubComponents it contains.

i do think we'll end up wanting a QGraphicsWidget subclass for SubComponents
(if there isn't aleady one?). this would be used to store information for
layouting, such as where it belongs in a bar (left, center, right?) and the
precedence (Home button should always be first precedent, left)