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
Stephan Rudlof wrote:
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.
I was merely thinking that using Sensor would imply the semantics that the hardware was indeed checked, whereas the Hand might opt to produce eg. the cursor position by interpolation or looking in an instvar.
The other thing about having these functions tied to the Hand would be a better abstraction, consider for example situations with multiple hands (such as remote stuff).
Neither is a big issue.
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...
Right, it doesn't encourage potential takers for porting to other platforms.
Tim Rowledge wrote:
So do I, unless it costs a lot - although keystroke and mouse button events are usually relatively slow (ie maybe a couple of hundred aminute at worst) some events (people have been considering serial or socket events for example) might be much higher bandwidth and could cause a problem if getting the time is costly.
I'm from a neutral (officially at least) country--let me try to be the mediator: How about only giving timestamps for those kinds of event which need it like those related to user input, and leave the timestamp as (potentially) undefined for the other kinds. I don't really see a need for time stamps for networking events. (What about serial? Midi does this in some other way, right?)
Henrik
squeak-dev@lists.squeakfoundation.org