[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Plasma Media Center and state machines
From:       Christopher Blauvelt <cblauvelt () gmail ! com>
Date:       2010-04-02 13:10:41
Message-ID: g2offa898c91004020610v33a8794cl6c1bd4eeacd3d17c () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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

[Attachment #5 (text/html)]

<div class="gmail_quote"><div>Perhaps I haven&#39;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&#39;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&#39;re going to use a plugin \
architecture then the whole point is that we don&#39;t know how many states we&#39;re \
going to have.  I really think the model-view framework is our friend here and, while \
I don&#39;t like the visual interface, MythTV has done a good job with defining a \
menu system.  When it all comes down to it, that&#39;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&#39;re at the home screen and the user selects &quot;Pictures.&quot;  \
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>



_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]