[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:       Alessandro Diaferia <alediaferia () gmail ! com>
Date:       2010-04-02 8:34:42
Message-ID: s2s65627f3a1004020134x39522c98k396665163cd454bb () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


2010/4/2 Marco Martin <notmart@gmail.com>

> On Friday 02 April 2010, Shantanu Tushar Jha wrote:
> > (My ideas, be free to kick ;)
> >
> > Hi Christophe, now I'm able to understand most of what you've
> > proposed. Somehow, I don't like having just one state machine for the
> > whole MC, the main reason being that we're going to support
> > extensibility through custom plugins, so the MC can no longer assume
> > that it knows exactly how many states are present.
> > What I propose is not altering the libraries, but to have a state
> > machine for each component (component as in the containment,
> > controller applet etc). Though I don't have code to show that right
> > now (i'm writing a small Qt app to demo it), I'll try to explain a
> > sample working-
>
> While i share the concern over extesibility (and wouldn't know how to do it
> with a single global state machine) how a state machine for each component
> would fix that?
> a part every plugin being a omplete set of new applets...
>
> Cheers,
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

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 :-).

So we can now have:
Pictures,
Videos,
Audio tracks,
Games,
Olographic films :-)
...

That's probably enough for now :-P

Cheers

-- 
Alessandro Diaferia
KDE Developer
KDE e.V. member

[Attachment #5 (text/html)]

<br><br><div class="gmail_quote">2010/4/2 Marco Martin <span dir="ltr">&lt;<a \
href="mailto:notmart@gmail.com">notmart@gmail.com</a>&gt;</span><br><blockquote \
class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, \
204, 204); padding-left: 1ex;"> <div class="im">On Friday 02 April 2010, Shantanu \
Tushar Jha wrote:<br> &gt; (My ideas, be free to kick ;)<br>
&gt;<br>
&gt; Hi Christophe, now I&#39;m able to understand most of what you&#39;ve<br>
&gt; proposed. Somehow, I don&#39;t like having just one state machine for the<br>
&gt; whole MC, the main reason being that we&#39;re going to support<br>
&gt; extensibility through custom plugins, so the MC can no longer assume<br>
&gt; that it knows exactly how many states are present.<br>
&gt; What I propose is not altering the libraries, but to have a state<br>
&gt; machine for each component (component as in the containment,<br>
&gt; controller applet etc). Though I don&#39;t have code to show that right<br>
&gt; now (i&#39;m writing a small Qt app to demo it), I&#39;ll try to explain a<br>
&gt; sample working-<br>
<br>
</div>While i share the concern over extesibility (and wouldn&#39;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 \
class="h5">_______________________________________________<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> \
</div></div></blockquote></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&#39;ll refer to. In the future, probably, we&#39;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&#39;s probably enough \
for now :-P<br><br>Cheers<br clear="all"><br>-- <br>Alessandro Diaferia<br>KDE \
Developer<br> KDE e.V. member<br><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]