[self-interest] event system (was: plans)

[Jecel Assumpcao Jr]

shaping at bigfoot.com wrote:
> I have a special interest in high-performance 3D graphics (currently in
> Squeak), but without using Qt-like C++ frameworks to achieve high speeds.

I don't know Qt, but have studied quite a few 3D frameworks and
never found one that I liked. I have a description of my idea at:

  http://www.lsi.usp.br/~jecel/gmodel.html

> I don't know what "slices" refers to.

It is an attempt to unify carpet morphs, text selections,
database queries and so on. The fourth item (or so) on the
following page describes the idea and the origin of the name:

  http://www.lsi.usp.br/~jecel/tech.html

> I would like details on your best concept for an input event system.

Hmmm... I don't seem to have anything on that, so I'll just copy
a description I sent to the Squeak mailing list about a year ago:

----------------------------------------------------------------
My idea is to have a set of components connected in
a graph-like structure. The graph's edges can be either
"push" (where the origin sends a message like #mouseDown:
to the destination) or "pull" (where the destination sends
a message like #curentCursorX to the origin).

A pushInput/pullOutput component is a buffer, like the
well known keyboard type-ahead buffer. A pullInput/pushOutput
object could be called a "pump", and can be quite handy
in certain situations. A filter is normally a push/push
component, but could also be a pull/pull one. They are  
linked in a 2D graph, so an object can pull from several
sources or send to many destinations if the need arises.

Now this graph is dynamic, and can change in response
to hardware changes (pluging in that new USB joystick)
user preferences (invoking Alan Kay's character         
recognizer) or application needs (after a drag is      
initiated you want to keep track of the cursor).      

The application should be able to "dip into" this event
graph at the points which match its semantic needs 
the best. If it needs to insert text in a morph then   
it should poll the TextMux object for input. At this     
point it could be seeing cooked input from a multi-       
language keyboard system, the result of a fancy voice
recognition system or even the interpretation of some
touch tones over the phone line. On the other hand,   
the toy piano app I mentioned above would be driven          
by virtual keyboard scancodes. In the same way, a      
program that needs gestures could get them from
a filter on the mouse or from a VR glove, while a
paint program might prefer to see mouse events
directly (not really, but you get the idea).

Extending Squeak with remote "hands", MIDI,
future facial expression recognition from video
and so on will become ever more difficult unless
something like I suggested is implemented.
----------------------------------------------------------------

and here were my replies to some comments on the idea:

----------------------------------------------------------------
"Ted K." <tedk at wdi.disney.com> wrote:
> > [event graph idea]
> I too have been feeling the need for something
> like this.  Any ideas on how to keep from computing
> the whole graph for each event?

This is only a problem for the "push" arcs of the
graph, not the "pull" ones. My solution would have
a filter (pushInput/pushOutput kind of component)
disconnect from its input (unsubscribe) whenever
it had nobody linked to its output and reconnect
(subscribe) when a new customer arrived. I think
that this (and what you describe below) would avoid
having events flow though any more of the graph
than strictly necessary.

Buffers are a problem (push/pull kind of objects)
because they stay subscribed and grabbing events all the
time, but I don't think anything can be done except not
putting them where they are not really needed.

> I picture the panes of a browser attaching and detatching
> themselves from the keyboard input pipe as
> you move the mouse over them.

That is the idea. It might be best not to take this
too far, however. Windows could work like this and
yet have a single "demux" object distribute the
events among the subpanes (or submorphs). This would
be a pull/push object - what I have called a "pump".
This scheme has the advantage of being compatible with
a lot of existing code.
----------------------------------------------------------------

> Why is Self 4.0-compatibility important?  If you understand clearly and
> completely what you are doing by creating tinySelf, then realize tinySelf,
> and forget everything else for now.

It is certainly easier to not worry about compatibility. But is the
Self 4.0 ports to the PC (or Java) work out, it might be worth the
trouble. An advantage in doing these things in Self 4 is that they
can be developed in parallel with tinySelf (not really an adavantage
if I do everything myself, of course).

> I want simplicity (a few broadly applied patterns), clarity, and minimality.
> >From these, we build the rest.  From these, also, we build and
> compartmentalize our Self 4.0-compatibility, if desired.

The Self motto is "the power of simplicity", after all!
-- Jecel


------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/self-interest
Free Web-based e-mail groups by eGroups.com