[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ship it with Squeak

Tim -

You're quite right.

I looked into events a bit back when I was working towards
a Squeak->Netwon port since the Newt is totally event driven at the user
application level. You can't ask the Newt where the stylus is on the
screen -- in fact it really wants to give you entire gestures (with
multiple segments) at once.

The biggest single issue was in MVC. IIRC (from 1.16), the MVC code for
many apps does some internal tight polling looking for mouse changes
that locks up the system, especially when waiting on a mouse up. If
these loops are still in the code they wouldn't be that hard to fix --
just tedious. Morphic does not have this problem -- just others related
to complexity and size :-) -- except that Morphic still is expecting
this non-event
mouse primitive at the bottom of everything, but I think that can be
changed in one place.

I don't think actually passing in basic mouse events through the VM
would be that hard. My approach for the Newt was planned to be a short
circular queue of mouse events maintained by the VM that the Smalltalk
could check by a new primitive and dispatch itself. This matched the
Newt's desire to produce gesture paths. There is also problem that the
logic for storing modifier keys in a global would have to be changed -
it would have to reflect what current point was being retrieved from the
stroke point buffer.
[The Newt had several other event-related issues (detailed on the Squeak
list on 27 Oct. 1997) which I won't go into.]

Other events like window close etc. might require more cleverness
related to allocating event objects and such. In general though, it
might be klunky but acceptable to poll for most external window events
(close, resize) as Squeak mainly spends time with its own windows. 

The same could probably not be said for socket events which might need
quicker response (or need "select" to operate well). File events and
semaphores might also need better support. 

The TCL event loop might be a good model here. I had a TCL expert spend
twenty minutes once extolling to me the virtues of TCL's event loop as a
key cross-platform feature (in contrast to Python's lack of an event
loop).
Any TCL internals experts on the list? Could we "steal" (legally under
the TCL license) the TCL cross-platform event loop code? Would it help
at the VM level?

One big issue here is that the Squeak VM is not reentrant so one needs
to tread carefully.  I guess in the end, for completeness, one might
just have to either generalize the event system to allocate Smalltalk
objects and poll in the VM, or generalize a primitive to request events
from the OS and modify all the Smalltalk code to use it.

Part of the problem stems from Squeak not making up it's mind about
whether it's an application or an OS. If you are putting Squeak on the
metal in a single thread it is probably easiest to implement if it does
poll (and maybe sleep). Then the current MVC handling of polling is a
good thing. If you think of Squeak as an application with another OS
thread serving it with events, then polling is probably a bad thing.

Anyway, that is how I see it.

How far have you got? What is your approach? 
Which platforms are you looking at?
I hope your changes make it into the main distribution.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Tim Rowledge wrote:
> 
> Paul Fernhout wrote:
> 
> > To me, the most important changes to do for deployment are:
> > * Making Squeak event driven at the VM level to eliminate those
> > occasional weird mouse drags
> Working on it. It's a _lot_ more than VM level work. Many bits of code
> use messages like anyButtonPressed or shiftDown etc which are really
> un-event driven ideas.
> Even the nearest-to-event parts make assumptions about checking the
> mouse and then the keyboard; not surprising when they are working of the
> current mouse-state plus keyboard-queue system.
> 
> tim