Igor I hope that mike will reply because normally ESUG will pay him to clean the event system. And I would love to have that integrated in pharo. Now I think that this is important to move one: Let us dream about 1 year time from now. And let us make it becoming true. I really want (this is not that fun to do) but I will do it rentlessly - remove etoys, bookmorph, (may be project ....) and then we should go to the next level, network, file, events. I know that Alien FFI is now in good hands :) So let us build a good and fun community to make this gem shine. step by step. I do not know how to call for more help but if you (guys listening) want to help please do it. Stef On Nov 15, 2008, at 1:19 PM, Igor Stasenko wrote:
Hello list,
it is strikes me, how complex event handling in squeak. :) I want to make it less fuzzy, but it looks like there is too much to do for achieving that.
In current state, it grew out from multiple evolutionary steps - old VM has no event queue, so at language side, it has to support two ways to fetch events from VM.
A key primitive which feeds an events from VM is in EventSensor>>primGetNextEvent: , which fills a provided array with 8 indices. It looks like a good point to reuse same array for fetching events, to not create new instance for each single event, right?
(in EventSensor>>fetchMoreEvents)
eventBuffer := Array new: 8. [self primGetNextEvent: eventBuffer. type := eventBuffer at: 1. type = EventTypeNone] whileFalse: [self processEvent: eventBuffer].
But hey.. let's look further:
EventSensor>>queueEvent: evt "Queue the given event in the event queue (if any). Note that the event buffer must be copied since it will be reused later on." eventQueue ifNil:[^self]. eventQueue nextPut: evt clone.
so, its avoiding creating new instance in #primGetNextEvent:, but then creating a new one later (by cloning it), e.g. instead of using single primitive which creates new instance & fill it with values, we use two primitives. Well, this strategy would be valid, if we, instead of putting raw event buffers into queue, first, decode the event and put a nice XXXXEvent instances instead. But this not happens in EventSensor, and i really disappointed and asking, why?
Instead, an EventSensor puts a raw event buffers (arrays with 8 values) in queue, and then gives them away! Which means that there is not a single place in image where you should deal with cryptic values returned by VM primitive.
I think, that first & most important task of event handling should be get rid of this cryptic looking array of 8 values, by deciphering them and replacing with an appropriate instances of some event, which having a good protocol & easy to manipulate/work with.
Consider an easy scheme, which can deal with deciphering event buffers into a nice events: First , we can associate each kind of event with a class. There is not much of them , defined in VM /* Event types. */ #define EventTypeNone 0 #define EventTypeMouse 1 #define EventTypeKeyboard 2 #define EventTypeDragDropFiles 3 #define EventTypeMenu 4 #define EventTypeWindow 5
So, all we need to do is to have an array of eventKinds , which contains appropriate classes for each event kind.
eventKinds := Array new: 5. eventKinds at: 1 put: MouseEvent. eventKinds at: 2 put: KeyboardEvent. ...
then, if we want to decode an event from event buffer, we can simply do:
newEvent := (eventKinds at: (eventBuffer at: 1)) decodeFrom: eventBuffer.
And voila, we can play with events as we like. e.g. instead doing something cryptic like:
type := eventBuffer at: 1. type == 1 ifTrue: [ ... ]
we can write code in more human friendly manner:
event isMouseEvent ifTrue: [. ..]
As you understand, this is only a tip of the iceberg. It is really scary piece of system, each time i'm looking at it, something tells me - hey pal, leave this stuff and never look at it again :)
P.S. I'm understand, that event handling code is born from multiple waves and being modified by different developers. And i'm appreciate their efforts, because despite the design it works!
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project