Mouse events

ocit.inc ocit.inc at MCI2000.com
Sun Jan 24 15:16:21 UTC 1999


An event driven interface architecture has been available in VW since 2.5 in
the form of a filein. It is now the default.

I believe that one of the main reasons why the polling architecutre was
employed was because it facilitated "portability".

Charles
OCIT
-----Original Message-----
From: Carl Watts <Carl at AppliedThought.com>
To: Joachim Durchholz <joachim.durchholz at munich.netsurf.de>
Cc: squeak at cs.uiuc.edu <squeak at cs.uiuc.edu>
Date: Saturday, January 23, 1999 8:23 PM
Subject: Re: Mouse events


>>> Its a common mistake, but the lack of [mouse] responsiveness is not
>>> due to the threading model. Its due to the use of a polling user
>>> interface. ...
>>
>>Thanks for clarifying this.
>>
>>> The solution lies in implementing an event model for mouse clicks.
>>> But this does require a rewrite of the simple (and hence easily
>>> extensible) Controller polling loop.
>>
>>Hm. If it's easy to do: Why hasn't this been done before?
>
>It has, several times.  I personally have done it three different times in
two different flavors of ParcPlace Smalltalk and once in Squeak (but it was
for a private company who retains the right to the code I wrote).
>
>Morphic, the new interface architecture in Squeak is written to be event
driven.  It's just the low levels of the user input system
(InputSensor/InputState and the VMs that aren't supportive of it yet).  And
of course the old interface architecture in Squeak, MVC, is not designed to
be event driven.
>
>Don't worry, it's a known problem. I'm sure it will be addressed in Squeak
before long.  It is unfortunate that polling MVC never seems to fully die.
Just when you think it's gone forever it appears again!
>
>
>Carl Watts
>http://AppliedThought.com/carlgwatts.html
>
>
>Carl Watts
>http://AppliedThought.com/carl/
>
>





More information about the Squeak-dev mailing list