From kde-panel-devel Fri Apr 02 13:10:41 2010 From: Christopher Blauvelt Date: Fri, 02 Apr 2010 13:10:41 +0000 To: kde-panel-devel Subject: Re: Plasma Media Center and state machines Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=127021393106462 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0659848519==" --===============0659848519== Content-Type: multipart/alternative; boundary=0016362843e6ce2c25048340b4b1 --0016362843e6ce2c25048340b4b1 Content-Type: text/plain; charset=ISO-8859-1 Perhaps I haven't been paying close enough attention but what is the need of the state machine? > So we can now have: >> Pictures, >> Videos, >> Audio tracks, >> Games, >> Olographic films :-) >> ... >> >> That's probably enough for now :-P >> > 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. To illustrate my point a little better: 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. Thoughts? Chris --0016362843e6ce2c25048340b4b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Perhaps I haven't been paying close eno= ugh attention but what is the need of the state machine?
=A0
So we can now have:
Pictures,
Videos= ,
Audio tracks,
Games,
Olographic films :-)
...

That's pr= obably enough for now :-P

Your joke I think proves that it would be better not to have one.= =A0 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.=A0 I reall= y 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.=A0 When it all comes down to it, that's what this really is.=A0= Instead of a state machine I think it would make more sense to have layout= s defined which you move to once a selection is entered.=A0 You can zoom an= d twirl your way there however you like.=A0 =A0 The layouts could be define= d via some kind of XML schema, like MythTV, or through some other means.
To illustrate my point a little better:
You're at the home scree= n and the user selects "Pictures."=A0 You move to the picture/alb= um browser layout where you can scroll to the album or picture that you lik= e.=A0 Your menubar changes based on parameters defined in the plugin instea= d of parameters defined in the part of the program that launches the plugin= s.=A0 This gives the flexibility to the plugin writer to define what he/she= wants without requiring changes to the main program.

Thoughts?

Chris
--0016362843e6ce2c25048340b4b1-- --===============0659848519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0659848519==--