Nice proof of concept!


On 30 Jan 2014, at 7:50 , gettimothy <gettimothy@zoho.com> wrote:

Hi Eliot, Bob and Henry.

Changeset and pic attached. (If the changeset has problems, let me know, I copied from my live CS to a clean copy to share that omits my fiddling around changes. I might have missed something)

I would appreciate your advice on how to proceed from here.

The approach is modeled after what I saw in HostWindowProxy.
I have other things on my checklist to try, but this seemed the easiest approach, so I ran with it.
My first goal was to just get the darned events into the simulator, see something on the simulated transcript  and a menu to show up.



Observations:

       The events get there and the WorldMenu pops up. woot. (lower case "woot", no exclamation point. not to be confused with WOOT!!!!)
       The tildes "~" in the simulation Transcript (in the attached pic) are generated at StackInterpreterSimulator>> ioGetNextEvent
       Event processing is dog slow. Be prepared to wait 5 minutes for the menu to pop up.

Was event coordinate translation somehow not needed, or did a click in top left of your screenshot end up opening the menu on mid right side?

       Tightly coupled.
        I don't like the modification to EventSensor.
        I don't like having to implement a Singleton--but it was saner than Smalltalk at: #StackInterpreterSimulatorLSB allInstances do:[…]

IMHO, If you just keep the EventSensor override code dealing with event delivery to the morph in a separate package, it would be just fine to delay exchange to a less intrusive alternative until later.
As long as the responsibilities are clear, it shouldn’t be too hard (push vs pull expected, who of deliverer/simulator morph does potentially needed coord translation, etc) 

        I am unfamiliar with Smalltalk Semaphores, had I known how to do the Smalltalk equivalent of event listener I would have gone that route.
        Consumer/Producer Semaphore examples from various books I have read are all within the same process, so I cut my losses and went with the current approach.


There’s already such a Semaphore operating across the VM/image divide, set by primitive 93. You can see an example of how to do an event listener using that in a Pharo images InputEventFetcher ;) 
(whose consumer action is… pushing the event to an in-image queue :P) 

Related, the morphic polling loop in Pharo images has been decoupled from the raw act of calling getNextEvent:, so for those correct signaling of the semaphore set by primitive 93 is required to get input processing simulated correctly .
Shouldn’t be harder to make it work than signaling said semaphore from ioProcessEvents if the eventQueue is not empty, provided the semaphore setter primitive is actually operational in the Simulator :P

Cheers,
Henry


       EventSensor>>processEvent:evt  does have the events in raw form, no need to translate before forwarding to the StackInterpreter.

       In principle, we know we CAN get the dang events into the StackIntepreter.

       How do I make this responsive and useful?

I’d say what you’ve achieved is already quite useful!
Maybe filtering out MouseOver events would cut down on the response time?
I would imagine the Simulator could be working up a hefty backlog of byte codes to simulate in order to process those... 

Cheers,
Henry