Dear Andreas, dear Tim!

I'm somewhat irritated. But this is normal, if there is such a discussion.

As user I'm interested in a *working* version of as much event code as
possible. Now there are two different drafts.
I think we strongly need a *common* source base in ST *and* C to make
further developments.

Some thoughts and comments are following.


0.

"Raab, Andreas" wrote:
> 
> * A somewhat different event format
> I've added support for time stamps (which we will need for determining
> double-click times etc) for all events, as well as a number of currently
> "reserved" slots for the defined events. I think that we may want to use
> these reserved slots for stuff like a window handle, Unicode characters, or
> meta-keys (such as function keys or similar).

I like the concept of time stamps.


1.

Tim Rowledge wrote:
> I think the changes to HandMorph etc that I included to improve their
> event behaviour are also very important. Without code analogous to that,
> there is very little point ot having any sort of event handling in the
> VM or anywhere else!

I second this.

Are Tim's changes to HandMorph, etc. compatible with Andreas' changeset?

I think this is an important point to be able to work further here. Wouldn't
it make sense to merge Andreas' and Tim's versions to a common base?
Currently we're in kind of a twilight zone...


2.

Tim Rowledge wrote:
> >
> > User interrupts. These are handled by the ioProcess running in EventSensor.
> That's a good improvement, essential if we really want to use a process
> to reap events. As I said in explanatory email.
> 
> >
> > I'm sending this CS as a base for discussions.
> Ok, so it's fine so far as it goes. It'll certainly work ok on the
> platforms I know anything about (though I _still_ can't find a way to
> get my &^%^ing Acorn to give me mouseUp events!) pretty well.

There seem to be consensus that Andreas has made some good additions.


3.

"Raab, Andreas" wrote:
> 
> Tim,
> 
> > > [Re: ST oops]
> > > > Huh? It makes SmallIntegers (or potentially LPIs I guess). What's
> > > > the problem with that?
> > >
> > > Two problems basically. #1 I simply don't like hacks like "#define
> > > INT_OBJ(val) (((val) <<1) | 1)" if there might be a cleaner solution.
> > So call integerObjectOf: or positive32BitIntegerFor: ; for a freely
> > declared hack to demonstrate that events can be done it's no
> > great crime to use a macro.
> 
> It's not a great crime but it's not a clean solution either. Calling
> #positive32BitIntegerFor: or any such function can cause a GC in which case
> the OOP provided may move and you have to keep in mind to remap it. As I
> said this can all be debugged, but then again, why bother?! That's the first
> part of why I don't want to expose the raw Smalltalk oop.
> 
> > > #2 is that for time stamping an accurate mask is required and
> > > forgetting it may cause trouble. Yes, all of this can be debugged
> > > but why even bother?! There is only one situation where one might
> > > argue that exposing the internals is  actually a good idea - which
> > > is when you want to return something different than an Integer
> > > (such as a string). But as I understand it, for the time
> > > being we won't have a use for anything but a number of
> > > integers so I'd rather not expose the details too much.
> > ?? you've lost me. What details are being exposed that you
> > don't like to expose? What has time stamping masks got to do with it?
> 
> For one thing see above. For the time stamp - the value returned by
> #millisecondClockValue is masked to fit into a positive SmallInteger value.
> Which means if you forget to mask it or (because of overflow of the VM msec
> representation) return a negative value, you will sometimes compute accurate
> double click times and sometimes you won't. Again, it can be debugged. And
> then again, why should there be any need for debugging it?!

I think we need a very good documentation here, if ST functions should be
used (don't use macros instead of interpreter functions here, please; the
definition of the VM may change). See below at 5. for a better way.


4.

Henrik Gedenryd wrote:
> > Raab, Andreas wrote:
> >
> >> The
> >> other possible use is for debug code - e.g., something like "Sensor
> >> leftShiftDown ifTrue:[self halt]" is very convenient.
> 
> I suggested some time before that all input events should go via the hand,
> including leftShiftDown and such. This doesn't need to actually look at the
> hardware. Is there a reason that I have missed for why the above wouldn't
> work for this too? (Hmm, perhaps we could make a HandMorph surrogate for MVC
> too?)

If we can successfully simulate hardware for MVC by using events; where is
the problem here?
I don't see much difference in using this simulated state polling by
HandMorphSurrogate>>someMethod or Sensor>>someMethod.


5.

"Raab, Andreas" wrote:
> 
> > > I'm still trying to figure out how to prevent the C
> > > support code from creating raw oops (another
> > > thing I don't like is that with Tims implementation you
> > > have to create oops yourself).
> >
> > Why not just pass a ByteArray to the primitive and let it
> > stuff in raw bytes instead of an Array (which you'd have to
> > create oops for)?
> 
> I don't really like ByteArrays here - too much interpretation imposed to the
> ST side where we really only need a handful of Integers. Note that I don't
> mind creating a couple of SmallIntegers from within the VM; the thing I
> don't like is that the C support code (e.g., a VM porter) has to know how to
> create ST oops. This can lead to fatal and hard to track down errors (such
> as when you have to mask the time stamp for matching the VM's assumption
> about what number of bits is reported by ioMSecs) so I'd rather pass out a
> plain C structure which the C support code fills in and the primitive code
> in the VM will map these into the appropriate ST representation.

This means to separate the C event generation in the support code from the
mapping of these C representation into ST objects (with potential GCs,
etc.).

Sounds reasonable to me and is an improvement of the status described in 3..

------------------

Suggestion: What about building a Tim-Andreas team? You are the experts here
and I think you'd reach a very good solution.
BTW: Possibly you are such a team yet...


Greetings,

Stephan