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