[squeak-dev] Re: Rewriting an Input/EventSensor code

Igor Stasenko siguctua at gmail.com
Sat Mar 21 10:09:33 UTC 2009


2009/3/21 Michael Rueger <m.rueger at acm.org>:
> 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.



More information about the Squeak-dev mailing list