<div class="gmail_quote"><div>Perhaps I haven't been paying close enough attention but what is the need of the state machine?<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><div class="h5"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So we can now have:<br>Pictures,<br>Videos,<br>
Audio tracks,<br>Games,<br>Olographic films :-)<br>...<br><br>That's probably enough for now :-P<br></blockquote></div></div></div></blockquote></div><br>Your joke I think proves that it would be better not to have one. If we're going to use a plugin architecture then the whole point is that we don't know how many states we're going to have. I really think the model-view framework is our friend here and, while I don't like the visual interface, MythTV has done a good job with defining a menu system. When it all comes down to it, that's what this really is. Instead of a state machine I think it would make more sense to have layouts defined which you move to once a selection is entered. You can zoom and twirl your way there however you like. The layouts could be defined via some kind of XML schema, like MythTV, or through some other means.<br>
<br>To illustrate my point a little better:<br>You're at the home screen and the user selects "Pictures." You move to the picture/album browser layout where you can scroll to the album or picture that you like. Your menubar changes based on parameters defined in the plugin instead of parameters defined in the part of the program that launches the plugins. This gives the flexibility to the plugin writer to define what he/she wants without requiring changes to the main program.<br>
<br>Thoughts?<br><br>Chris<br>