I'll just have to try and see how far I get with a single state machine. I think that Shan's idea could work but also think that extending things would mean writing new states for all applets. For me it seems easier to write a top level state which can direct infromation to all applets. The applets wouldn't need to know any states, they would just do what they are told. <br>
<br>Could any new future states simply be added to the State enum in the library? Would extending it be some form of binary incompatibilty or something?<br><br>Chris<br><br><div class="gmail_quote">On Fri, Apr 2, 2010 at 10:34 AM, Alessandro Diaferia <span dir="ltr"><<a href="mailto:alediaferia@gmail.com">alediaferia@gmail.com</a>></span> wrote:<br>
<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 class="gmail_quote">2010/4/2 Marco Martin <span dir="ltr"><<a href="mailto:notmart@gmail.com" target="_blank">notmart@gmail.com</a>></span><div>
<div></div><div class="h5"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Friday 02 April 2010, Shantanu Tushar Jha wrote:<br>
> (My ideas, be free to kick ;)<br>
><br>
> Hi Christophe, now I'm able to understand most of what you've<br>
> proposed. Somehow, I don't like having just one state machine for the<br>
> whole MC, the main reason being that we're going to support<br>
> extensibility through custom plugins, so the MC can no longer assume<br>
> that it knows exactly how many states are present.<br>
> What I propose is not altering the libraries, but to have a state<br>
> machine for each component (component as in the containment,<br>
> controller applet etc). Though I don't have code to show that right<br>
> now (i'm writing a small Qt app to demo it), I'll try to explain a<br>
> sample working-<br>
<br>
</div>While i share the concern over extesibility (and wouldn't know how to do it<br>
with a single global state machine) how a state machine for each component<br>
would fix that?<br>
a part every plugin being a omplete set of new applets...<br>
<br>
Cheers,<br>
<font color="#888888">Marco Martin<br>
</font><div><div></div><div>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org" target="_blank">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
</div></div></blockquote></div></div></div><br>I like the extensibility idea too but i think that we are bound to the definition of a set of possible states. We can try to look forward as much as we can and define such states. Plugins will just specify which of those states they'll refer to. In the future, probably, we'll update our libraries with the states that we could have never imagined in the past :-).<br>
<br>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><br>Cheers<br clear="all"><font color="#888888"><br>-- <br>Alessandro Diaferia<br>
KDE Developer<br>
KDE e.V. member<br><br>
</font><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br>