<div class="gmail_quote"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I like the idea of the state machine and how it could help us correctly managing the workflow of the mediacenter. Unfortunately i feel something in the current implementation lacks of robustness (does this word exist?).<br>
<br>
As Aaron pointed out, we need to understend whether we are aproaching this the right way.<br>
<br>
The mistake with the MediaLayout in this patch well shows that we should probably re-design something. The need for states is due to the fact that we want PMC to know the current media in order to differently behave and interact with the user. This way we could give the best set of actions for each kind of media chosen by the user.<br>
The first clear issue was the lack for a way of changing the UI accordingly to the chosen media.<br></blockquote></div><div><br>Here is a list of the issues we need to tackle correctly and agree on where to do it<br>Things that change on a state switch:<br>
<br>* The applets (called UIComponents) get a new set of widgets. Some widgets are always the same. These I called MainSubComponents and are only added once at PMC initialization. Others change with each state, these are shown/hidden on each state switch.<br>
->adding MainSubcomponents is currently handled by the MediaCenterState class, adding subcomponents is handled by the different state classes.<br><br>*The MainSubComponents and SubComponents are connected to public slots/signals of the applets.<br>
->This happens only once at PMC initialization, either by the MediaCenterState class, or the state classes themselves<br><br>*The MainSubComponents and SubCompomnents are connected to slots of the medialyout. This is needed to handle toggling autohides and things like that. This is only done at PMC initialization<br>
->again tis is handled by the MediaCenterState class for MainSubComponents or the state classes themselves for SubComponents.<br><br>*On each state switch the UIComponents get told to switch configuration, like show/hide, or load a ceratin dataengine for the mediabrowser, maybe load a playlist setting,...<br>
->This is handled by the state object classes themselves<br><br>*On each state switch the layout needs to put the UIComponents in to a certain state, like show playlist by default in music state,...<br>-> handled by the state classes<br>
<br>All this is handled by the state classes, but initiated by the containment which hands out pointers of the medialayout, or the UIComponents. The advantage of this is that we have all configuration stuff collected in one place, namely the state classes. We just need the containment to be able to find all state classes and iterate over them. Extending PMC would just mean adding a new state class.<br>
<br>A question is where do we handle the animations? In the state classes, or the containment?<br><br>One thing missing is the layout of the actual subComponents in the applets. Currently they are just added in a row. For this we need the API. The layout should recognize which type of applet arrives and lay it out accordingly. That means lots of if/thens within tha applet code. This also means adding new states with new subcomponents would mean adding if/tehns to the actual addToLayout functions in the applets.<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I'd go with questions here in order to better summarize what we need in the PMC:<br>
<br>
Q1. When do we need the UI to react to media type changes?<br>
R1. The UI should show different possible actions to the user both while browsing to a personal collection of e.g. videos and when actually reproducing a video.<br></blockquote></div><div><br>Agreed. This will mean having parent states (Music, Picture, Vide) but also Child states for each (browsing, sllideshow, playing,...)<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Q2. How the PMC knows which kind of media are we browsing through/reproducing ?<br>
R2. The PMC::Browser API should be updated in order to expose this kind of information. In addition to this the PMC::Player should be used in order to retrieve this kind of information while reproducing media.<br></blockquote>
</div><div><br>We can also control this oursleves. On state switch, the browser will only be able to change those media types allowed in that state, by setting the mediabrowser to the correct dataengine. So we actually do not need to act on the selected mediatype, because we can be sure that only one type is visible to the user. Does this sound too crazy?<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Q3. Are media types mutually exclusive?<br>
R3. This (unfortunately?) cannot always be true. The user might want to start his favourite playlist and then run a slideshow of his summer photos. Probably the PMC::Player should inform whether music is currently playing in background. I'd like to know from you whether you think music is the only media type that can be played in background while reproducing something else in foreground. This is an important topic IMHO.<br>
</blockquote></div><div><br>The way I see it, we will allow states to remain in the background if they are paused, or playing. This does not interfere with the mutual exclusivity of media types, because the player can play some music, but still the UI can be in a picture state. It's only the player that needs to be able to have more than one instance active, one plays music in the background, the other displays pictures. If I want to go back to my music, I need to go the the music state again, so actually away from the videostate. The UI adapts accrodingly, but the videostate is still active in the background. I hope I expressed myself clearly in some way.<br>
So only the player needs to know if he is in the background or not. I imagine small icons next to the home icon that are only there if a player instance is currently havinig some media active but is not shown. Clicking on that icon would switch to the accroding state.<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Q4. Which UI controls does the PMC need?<br>
R4. The PMC needs of course playback controls for the current media. In addition to this the browser should allow the user to navigate through his collection of medias and eventually get back to the welcome page. The welcome page should IMO be inside the browser.<br>
</blockquote></div><div><br>Agreed. The welcome page should be the browser showing all possible dataengines grouped by media type. In this state, all other aplplets are hidden. What about current active/background states. Maybe the control bar can go into autohide mode and only show the latter. <br>
</div><div><br>I think that once we agree on where things are handled we can start hacking on the details again. I feel that more or less we want the same things but are not really sure how to get them. In that regard I would like to express that I will be happy if you take my code and turn it upside down completely to get it to do what we want, or rip it out again. This is all a nice ride for me and I will not feel turned down or something if you thing my coding is bad, or my way of seeing the redesign is.<br>
<br>Please test abit the current way of doing things before seeing it as too complex.<br><br><br>Cheers<br><br>Chris<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div><div><br>
><br>
<br>
</div></div></blockquote></div><br>
</div><br>