>> > 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 this is something like that that I would like. > (What is recorded in recentModifiers should be queried directly from event > during handling, not through HandMorph) > And it would also make rewriting handleEvent: to something less... intrusive > wrt Event modelling a much simpler task later on. Yes I'm taking notes about these points. Now the first level for me is to handle raw VM events then after we will deal with morphic ones. > > Cheers, > Henry > >
