On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood <
aleric.inglew...@gmail.com> wrote:
> Morgaine, I *completely* agree with you! [?]
>
> One of the two main reasons, if not the only two, that we need this state
> machine approach *is* for client-side scripting and for plugins. Both are
> infinite
On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood <
aleric.inglew...@gmail.com> wrote:
> (sorry, but any 'secret' work that I never heard of before from whoever is
> working on it on this list has to be ignored),
Just because you haven't heard about something doesn't mean that others
haven't.
L
Morgaine, I *completely* agree with you! [?]
One of the two main reasons, if not the only two, that we need this state
machine approach *is* for client-side scripting and for plugins. Both are
infinite flexible in nature and require in principle hooks into the viewer
code to *control* the viewer o
State machines are very useful, but the use case you gave is an example of a
user application that should be coded in an attached script. The fact that
the viewer does not yet have attached client-side scripting is not a reason
for putting the user application directly into the viewer. It's a rea
Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the
viewer:
A state machine.
I'd add a base class from which others can derive their own classes.
A new state machine would then be started by creating one or more objects
of those types.
It would be a class that supports a chain
