Re: [Pharo-project] [squeak-dev] Re: Rewriting an Input/EventSensor code
2009/3/21 Andreas Raab <andreas.raab@gmx.de>:
Igor Stasenko wrote:
Recently , we discussed it with Andreas, and had an idea to integrate this with Announcement framework (and Announcement will become a core package).
Actually, Jecel propsed the combination.
Here is my vision , how things should look like:
[... big snip ...]
Michael, Andreas, i'd like to hear your comments and remarks, as well as any others are wellcome.
It's too much to do all that in one go around. What I would propose is to start simple by having an event source which maps from raw event buffers to some kind of (non-morphic) event objects and have InputSensor be a client of that. I believe that is a straightforward extension of the work that has already been done.
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?
Cheers, Â - Andreas
-- Best regards, Igor Stasenko AKA sig.
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. 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. 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 :-) Michael
2009/3/21 Michael Rueger <m.rueger@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.
On 21-Mar-09, at 3:09 AM, Igor Stasenko wrote:
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.
For the iPhone VM I return a complex event type, which then points to Smalltalk objects which are the representation of the touch events. For location and acceleration data I return the actual objective-C objects. This data is then processed by EventSensor. If you choose to push the responsibility to the VM for creating event objects then you need to be cognizant of the fact that whatever is proposed has to change very little over time, otherwise you end up with the issue of image versus VM compatibility and the fact that VM version changes proceed at a slow rate. -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
2009/3/21 John M McIntosh <johnmci@smalltalkconsulting.com>:
On 21-Mar-09, at 3:09 AM, Igor Stasenko wrote:
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.
For the iPhone VM I return a complex event type, which then points to Smalltalk objects which are the representation of the touch events. For location and acceleration data I return the actual objective-C objects. This data is then processed by EventSensor.
If you choose to push the responsibility to the VM for creating event objects then you need to be cognizant of the fact that whatever is proposed has to change very little over time, otherwise you end up with the issue of image versus VM compatibility and the fact that VM version changes proceed at a slow rate.
Nope. I don't want VM to deal with real event objects. VM will still use the old event buffers to deliver events to image. But once image receiving it, it should convert it to an instance of event as soon as source. This is the role of EventSource class - represent VM as event source, which producing an instances of KernelXXXEvent classes, and hiding the details of converting raw event buffers from the eyes of higher layers, which then going to handle the event (EventSensor/Morphic etc)
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com ===========================================================================
-- Best regards, Igor Stasenko AKA sig.
2009/3/21 Igor Stasenko <siguctua@gmail.com>:
2009/3/21 John M McIntosh <johnmci@smalltalkconsulting.com>:
On 21-Mar-09, at 3:09 AM, Igor Stasenko wrote:
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.
For the iPhone VM I return a complex event type, which then points to Smalltalk objects which are the representation of the touch events. For location and acceleration data I return the actual objective-C objects. This data is then processed by EventSensor.
If you choose to push the responsibility to the VM for creating event objects then you need to be cognizant of the fact that whatever is proposed has to change very little over time, otherwise you end up with the issue of image versus VM compatibility and the fact that VM version changes proceed at a slow rate.
Nope. I don't want VM to deal with real event objects. VM will still use the old event buffers to deliver events to image. But once image receiving it, it should convert it to an instance of event as soon as source. This is the role of EventSource class - represent VM as event source, which producing an instances of KernelXXXEvent classes, and hiding the details of converting raw event buffers from the eyes of higher layers, which then going to handle the event (EventSensor/Morphic etc)
To give an example what i talking about, here the bits of prototype implementation: KernelEvent class>>initialize "Initialize the array of event types. Note, the order of array elements is important and should be same as event type returned by VM in event buffer" EventTypes := { KernelMouseEvent. KernelKeyboardEvent. KernelDragDropEvent. KernelMenuEvent. KernelWindowEvent. } ----- KernelEvent class>>fromBuffer: eventBuffer "Decode a raw VM event into an instance of KernelEvent subclass" | type | type := EventTypes at: (eventBuffer at: 1) ifAbsent: [ ^ KernelUnknownEvent from: eventBuffer ]. ^ type new from: eventBuffer ----- KernelEvent>>from: buffer "Initialize an event instance from raw event buffer. Note, all subclasses should call super to initialize fields correctly" eventType := buffer at: 1. timeStamp := buffer at: 2. timeStamp = 0 ifTrue: [timeStamp := Time millisecondClockValue]. windowIndex := buffer at: 8. ---- KernelMouseEvent>>from: buffer super from: buffer. position := Point x: (buffer at: 3) y: (buffer at: 4). buttons := buffer at: 5. modifiers := buffer at: 6. as you can see, there is nothing complicated. It simply frees underlaying event handling layers from deciphering event buffers by themselves, instead, they deal with first class even objects, with harmonized protocol.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
participants (3)
-
Igor Stasenko -
John M McIntosh -
Michael Rueger