Hi All,

I have some primitive event filtering in place and was able to open a Workspace and type a message. See the attached screenshot.

I figure my work is at the stage where it would benefit from other eyes and minds.

For testing, I merged the attached changeset into 4.5 release candidate 3 after installing the CogDev stuff here: http://www.squeakvm.org/svn/squeak/branches/Cog/image/Workspace.text

I copied over the changes and it worked fine. One caveat is that I have the bug-fix for WriteStream nextChunkPut: in that change set. you probably don't want that.

To launch the thing, see StackInterpreterSimlatorMorph class > documentation protocol for examples on launching (currently 1 example (:)


Below are some notes.

Category and source
    1.added category VMMaker-InterpreterSimulation-Morphic which contains 3 classes
       StackInterpreterSimulatorImageMorph
       StackInterpreterSimulatorMorph
       StackInterpreterSimulatorMorphicModel
       EventSensorConstants is added as a poolDictionary to the model

  2. Additions where made to HandMorph. Most are in category *VM.oscog except for one edit to HandMorph>>processEvents

  3. Some modifications to StackInterpreterSimulator.

  4. I think that's all.






Event forwarding

    1. What I call "primitive events" are much easier to use (for me) than un-wrapping morphic events.

    2. I modified HandMorph by adding a primitiveEventListener framework that mimics the existing HandMorph >> addEventListener:/sendListenEvent:to:/handleListenEvent: framwork.
       
       See HandMorph >> addPrimitiveEventListener:/sendListenPrimitiveEvent:to:/handleListenPrimitiveEvent.
      
        For morphic events, listener notification happens in HandMorph >>  handleEvent. For the primitiveEvents, I had to use HandMorph >> processEvents.

    3. If this is un-acceptable, then the task of 'decoding' the Morphic Events that HandMorph creates in HandMorph >> processEvents needs to be done.
        I prefer to not do it as it is ugly.

    4. Primitive events from HandMorph are passed to StackInterpreterSimulatorMorphicModel after being registered with HandMorph.
       1. The StackIterpreterSimulatorMorph >> displayView registers the model with the HandMorph for event notification.

    5. StackInterpreterSimulatorMorphicModel >> handleListenPrimitiveEvent: evtBuf is where event translation and filtering happens.
       1. This needs a deft hand. Preferrably by somebody who is familiar with Morhic bounds translations. I briefly looked at it and its a deep subject, so I ran away screaming.
       2. You can un-comment some code to see the raw events on the transcript. I found this handy.
       3. EventSensorConstants has a list of other events that you may want to forward.

    6. Event's are queued in StackInterpreterSimulatorMorphicModel >> handleListenPrimitiveEvent: and dequeued in StackInterpreterSimulator >> ioGetNextEvent.


Tests
    1. I have not written any yet.
    2. The morph is copied from PreferenceBrowser, so I guess I need to look at those tests.


StackInterpreterSimulator notes.

    1. Rule 1 is to not break the existing openAsMorph functionality Eliot has.

    2. StackInterpreterSimulator >> openAsStackInterpreterSimulatorMorph launches it. (see StackIntepreterSimulatorMorph class ttyOne for example script)

    3. StackInterpreterSimulator is the instance variable 'vm' on the morphic model.

    4. There is tight-coupling of the StackInterpreterSimulator's displayView variable across all three layers (Morph-Model-VM) I had a good reason for this, but I forget what it was.

    5. StackIntepreterSimulator >> incrementByteCount is what triggers the display redraw. This needs attention.
           I changed the count to 1000 from 10,000 to trigger the forceDisplayUpdate call and got some improvement. Things I am wondering
       1. Should we change these triggers to options on launch?
       2. Should we make them variable?
       3. We can force a fullDisplayUpdate from the GUI, (Which I tried).
       4. Instead of a byteCount triggering it, what else would make sense?


Morphic improvments needed
    1. Event bound translation  in StackInterpreterSimulatorMorphicModel>> handleListenPrimitiveEvent
        I looked at this briefly and its a deep subject, so I took the easy way out and reverted to addition on x/y coordinates. (:

    2. Mouse and Keyboard events are forwarded when mouse is within the bounds of the ImageMorph.
      

    3. z-order does not stop events from being forwarded. For example,but a Browser over the simulation and events are still forwarded.

    4. Mouse drag moves the entire simulation window--I cannot drag a window within the simulation.

    5. Splitters and scroll-bars, splitters and scroll-bars (my first morph attempt, sorry)

    6. Buttons and callbacks.

    7. Bert's SqueakJS windows along the bottom--what makes sense to put there? How to do it?

    8. See class commments in StackInterpreterSimulatorMorph

    9. Help button contents

    10. Tim R's "WTF goes on in there?" button has not been implemented. Its very doable;  events just need to be enqueued for the simulator to suck them up.

    11. Eliot's command window menu needs testing. I know the clone vm does not work in this simulation. (it does work in the original openAsMorph simulation)


Summary
       1. It's usable enough now that I think submitting it is a good idea
    
        2. I expect to improve it as I learn more

       3. I would like to move on towards my goal of porting the StackInterpreterSimulator to native 64.


cheers.

tty