Carl -

>I was going to make a comment about 'polling' to find out when the Display is resized.  I was going to recommend instead a new input event from the VM come into InputSensor instead.  So much more tidy...
>
>I just assumed that InputSensor had been converted by now to get events from the VM (as we had done at Interval in our Squeak-based project there).
>
>But when I looked at class InputSensor, I found to my amazement its still polling based (with all the problems of missed events and wasted cycles that implies).
>
>Admitedly I don't follow the discussion on this squeak list as often as I'd like.  Is there some reason why InputState has never been converted to reaping 'events' from the VM rather than polling?  Or is it just that no-one doing Squeak development has gotten around to it yet?

This is the reason.

>Perhaps it remains polling in an attempt to avoid requiring the VM to poll on some platforms?  No, that couldn't be it, the VM already polls for the interrupt key on some platforms.
>
>Would it help to post the version of class InputSensor I wrote for Interval's event-driven version of Squeak?  It might help some though much of the difficult work was in the two new primitives it used.  Implementing those new primitives on all of Squeak's different platforms would be a chore & a half.  Perhaps the platform spread has gotten too wide to expect the new primitives it requires to be implemented on all platforms?

It couldn't hurt.  I would say the most useful thing would be to get one platform actually running with the primtives, but in a way that any platform that failed the primitives could go on polling.

I believe that once we had that state of affairs, then peer pressure would bring about the necessary implementation on the remaining platforms, with no single one constituting a greatly onerous burden.

	- Dan