2009/3/21 Michael Rueger <[email protected]>: > Igor Stasenko wrote: > >> Wait, i proposing nearly same: Have an event source which produces >> (non-morphic) event objects and InputSensor. >> I just want to know where Announcements takes part of it, or should be >> postpone that for a next step? > > What I did while exploring an alternative UI framework was to use the > rewrite and add an Announcer as a second listener. "Interested parties" > could then subscribe to event announcements. The raw input events are first > converted to first class event objects before submitting them to the > announcer.
Right, but here we're talking about doing such conversion much more earlier (at event source object), so then event sensor already deals with first class event objects. I want to know, if such scheme (which i described in first post) is plausible. > As discussed earlier this allows for having a completely separate UI running > without any overlaps to morphic. Tweak always had the problem of still being > tied into the morphic event processing, the combination of the sensor > rewrite and announcers avoid this. > Right, that's why we need a separate set of classes (i called them KernelXXXEvent) which representing an events which came from VM and not tied to Morphic. > I meant to make this stuff available a long time ago, partly as an effort to > try to avoid duplicate effort with the Alain's Miro framework, but kept > distracted by other things. > Will put it a bit higher on my list :-) > Let me know, if you need some help. At least i can send you a proto implementation of KernelXXXEvent classes. I'm also started writing it, but then other things drawn my attention :) > Michael > > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
