[squeak-dev] Rewriting an Input/EventSensor code

Igor Stasenko siguctua at gmail.com
Sat Mar 21 00:16:53 UTC 2009


Hello lists,

I making a cross-post, because there are interest from both camps to
make it done :)

Michael published a changesets with new event sensor code for Pharo,
which mainly focused on supporting multiple event
consumers(frameworks).
Recently , we discussed it with Andreas, and had an idea to integrate
this with Announcement framework (and Announcement will become a core
package).

I very like this idea, but i think we should discuss the
implementation details before starting it.

Here is my vision , how things should look like:

- role 1. Event source. VM, is an events source, in most cases it is
the only source, but not always. I would like to be able to plug-in a
different event source.. imagine a remote socket connection, or
previously recorded events and then replayed. So, an event source
should be a separate, abstract entity, where VM is one of the concrete
kind of it. There is also, sometimes a need to inject a fabricated
events into event queue, to simulate user input, or for producing a
synthetic events.

- role 2. Event listener/Event sensor (or InputSensor) is a mediator
between event source and higher level framework (Morphic.. etc), its
role is to listen events from event source and then dispatch it to
concrete consumer(s), if any.

- role 3. Events. Events should be a full featured objects, with good
protocol. A high level framework should not peruse with raw data, as
it currently does with raw event buffers which coming from VM. This
means, that changes will affect the Morphic. Morphic having a classes
for user input events (keyboard/mouse) and decifering raw VM events
into own representation. I think we should move the 'decifering' part
to EventSource (sub)classes, and make sure EventSensor (and its
consumers) dealing with full featured event objects, leaving event
consumers free to decide what to do with them.

- role 4. Event consumers. Note, there can be multiple different
consumers, not just one, as its currently Morphic. We should make
sure, that integration with any other framework will be painless.

- be ready for supporting multiple host windows. This part is quite
simple to do in EventSensor.. but not so simple in Morphic. One thing
would be is to refactor all code which uses the Sensor global
directly, and replace it with appropriate thing(s). But this is out of
scope of event handling framework, at initial stage , we could keep
things compatible with old ways (1 Sensor, 1 Display, 1 Morphic
World).


I started prototyping a classes for events, where each event kind
having own event subclass, and directly decoding the VM raw event
buffer, so then any event consumer(s) don't have to poke raw events.
But since there were a good idea to make use of Announcements for it,
it may need some refactoring.

Michael, Andreas, i'd like to hear your comments and remarks, as well
as any others are wellcome.

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list