On Sep 11, 2012, at 4:23 PM, Henrik Sperre Johansen wrote: > 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.
I think it's just because I wasn't aware that this class existed :) I should fix that Ben
