On 11.09.2012 15:41, Igor Stasenko wrote:
On 11 September 2012 15:27, Henrik Sperre Johansen
<[email protected]> wrote:
On 11.09.2012 14:35, Stéphane Ducasse wrote:
Hi igor
I started to reread again the code of EventModel that we started and I
browse the rest of the system….
gloops…
DropEvent>>sentTo: anObject
"Dispatch the receiver into anObject"
self type == #dropEvent ifTrue:[^anObject handleDropMorph: self].
DropFilesEvent>>sentTo: anObject
"Dispatch the receiver into anObject"
self type == #dropFilesEvent ifTrue:[^anObject handleDropFiles:
self].
it seems to me that sentTo: is a kind of double dispatch but not yet
there.
I do not see here the added value of the check except if this is to cancel
event.
Stef
I guess it's to be consistent with other types of events, and/or make it
easy to add a type instvar in the future...
Right now all three combinations of type instvar checks (KeyboardEvent),
subclassing (DropXEvents), or a mix of the two (MouseEvents) are in use
during the double dispatching of input events.
You might think subclassing was only used if additional state was needed,
but that's only true of MouseEvents, and not DropXEvents...
(So yeah, your observation that the type check in DropEvent is unneccesary
is correct)
It might be nice with a rewrite to rely on subclassing alone, albeit
increaseing the number of event classes. (KeyUp, KeyDown, KeyPressed,
MouseOver, MouseEnter and MouseLeave for sure, potentially more depending on
what action in WindowEvent means)
A benefit is you could rewrite processEvents loop to essentially read
event := MorphicEvent forBuffer: evtBuf.
self handleEvent: event
yes, that's the idea. but we didn't went further than passing events
to HandMorph.
At first stage we want to make sure a lower-level event handling
(Sensor->World->HandMorph)
can be replaced with new model, and then we can enter the morphic and
clean it up more seriously.
Mmmmhmm, isn't it more accurate to say that events flow Sensor ->
HandMorph -> World?
(Though, they get pulled in by the consuming world in a polling loop,
rather than getting pushed from the flow source)
Anyways, a proper input event modelling is really independent of
Morphic, analogous to the WindowClosed/MorphicWindowClosed naming
discussion.
(which also gives a third alternative to double dispatch/case, in that
in use registering to them tend to look like case statements, but
loosely coupled)
Cheers,
Henry
PS: Looking up an example WindowAnnouncement and ran across it; WTF does
Nautilus need special NautilusWindowAnnouncement classes for?
As long as your announcer is a Nautilus-specific one rather than the
default announcer, that's all the separation that's needed...
In other words; favour application-distinct announcers over duplicate
Announcement types.
