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

Wed Apr 7 19:14:22 UTC 1999

----- Original Message -----
From: Jecel Assumpcao Jr <jecel at lsi.usp.br>
To: <shaping at bigfoot.com>
Cc: <self-interest at egroups.com>
Sent: Wednesday, April 07, 1999 9:24 AM
Subject: event system (was: plans)

> 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

This sounds reasonable, but I was thinking at a somewhat higher,
widget-component-connectivity level.  Jecel, please study the signal/slot
architecture used by Troll Tech (http://www.troll.no/products/qt.html).  I
want to avoid C++ at all costs, but the basic idea has nothing to do with
that language.  I think their signal/slot pattern can be adapted to Self,
where it would be more readable and run at comparable or faster speeds.
Please let me now what you think.

>
> > 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

Yes, good idea, but I don't see clearly how to implement it.  We definitely
need the power of "class controls all instances" but without classes proper
(or conventional).  I'm not fluent enought yet with Self to be of much help
now, in this regard.

So, why again are we not implementing Self or tinySelf on Squeak just to
test out some of these ideas?  I would love to do that.  We have good
imaginations, but they are not that good, and we all know that.  We need to
do some real programming and bump into some real walls.  Do you think the
Squeak implementation of Self is not worth the effort based on where your
progress stands on tinySelf?

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

This looks like it has merit, but seems a little vague.  Can someone give me
an event-by-even, object-by-object contrived scenario that illustates how
these push-pull buffers/pumps might work.   From the description, I'm not
certain whether graph nodes are objects like keyboard and mouse, or event
queues of some sort.

>
> > 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!

Didn't I see someone else on the Web working on a Squeak implementation of
Self?  A company I think.

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