Henrik have a look at EventModel/EventModel because this is were we publish our vm event brain surgery.
>> 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. Open a bug entry and send code. I'm sure ben will be happy > >
