Revision [312]

This is an old revision of ioGetNextEvent made by JohnMcIntosh on 2008-10-21 20:30:50.


sqInt ioGetNextEvent( sqInputEvent *evt)

Evt is a pointer to an array of words that we populate with event data.

return: NONE, fake return of zero
Can set success() to fail, not fail the primitive

From: Interpreter
To get FIFO UI event data from the UI

Most VMs have a FIFO queue that contains subclasses of sqInputEvent to record mouse, keyboard, drag/drop, menu and window events.
Most VMs call ioProcessEvents if the queue is empty

ioProcessEvents is always called.


Uses proper multi-threaded Queue class for the FIFO queue

Adds a new event type that indicates we have a pending complex data object to return. This data object is to support the
multi-touch UI. The smalltalk event queue processing logic has to make a different call to fetch the data from another queue.
This requires a change to the currently shipping VMMaker to allow us to pass up a smalltalk object, versus just integers.

IF there are no events it calls ioProcessEvents, otherwise return next event on queue. Queue is not locked

IF there are no events it calls ioProcessEvents, otherwise return next event on queue. Queue is not locked

Most VMs don't consider locking the FIFO queue, are they all thread safe?
Some VMs return true/false, but the return value is ignored.

Thoughts on events:

typedef struct sqMouseEvent
int type; unsigned int timeStamp; int x; int y; int buttons; int modifiers; int reserved1; int windowIndex; } sqMouseEvent;

timeStamp is the ms clock ioMSecs()
x, y are the mouse location in pixel coordindates local to the window
windowIndex is the index number for the window that posted the mouse event.

To complicate things you have 4 different type of events that can occur button down, button up, mouse move, and mouse wheel event
For the mouse wheel event we translate that into synthetic events for keyboard entry using cursor up/down/left/right based on the mouse wheel geometry and the number of cursor events then map to some unit of measure for the wheel (usually one unit of wheel movement means one cursor movment).

Since mice have 1 or more buttons we support the traditional three Smalltalk buttons (red, yellow, blue), these can be generated by having a mouse with the right physical buttons, or by using a single button mouse with alt/control/cmd/option modifier keys to indicate alternate button down choices.

From wikipedia: "The ground-breaking Xerox Parc Alto and Dorado computers from the mid-1970s used three-button mice, and each button was assigned a color. Red was used for the left (or primary) button, yellow for the middle (secondary), and blue for the right (meta or tertiary). "

We cache the old event and compare to the new event based on button state, mouse point location. If the data is the same we don't forward that to the queue. This is needed on systems that have some sort of polling and would return cursor at x,y, cursor at x,y every 16ms, versus generating a new event only if the state is different.

Please note it is possible then to generate button down at 10,10 followed by mouse moved at 10,10 (with button down), which seems a duplicate, but in one case the button went down, the other it moved.


On the macintosh get mouse location, map to local coordinates, we use the info-plist to map the button logic to a desired button logic for running as an application, or running via the browser. In both cases we end up swapping the buttons to first deal with cmd/opt/alt usage, or to deal with cases where the user might have a two or three button mouse.

Events handled are:

{ kEventClassMouse, kEventMouseMoved},
{ kEventClassMouse, kEventMouseWheelMoved},
{ kEventClassMouse, kEventMouseDragged},
{ kEventClassMouse, kEventMouseUp},
{ kEventClassMouse, kEventMouseDown},
{ kEventClassMouse, kEventMouseEntered },
{ kEventClassMouse, kEventMouseExited }

kEventMouseEntered, and kEventMouseExited are not presented as mouse events, they are used to alter the cursor from the default cursor to the cursor set by Squeak when it enters or exits the window.

The macintosh does not have good control over modifier key changes, so on a kEventRawKeyModifiersChanged we fake a mouse move
so that EventSensor caches the state of the modifier keys.



There are no mouse events on the iPhone. Rather there are touch event sets which bundle up and give back in ioGetNextEvent. Then code in the EventSensor processes the complex event and dispatches the proper mouse down,move, up events. There is no way to indicate other mouse buttons since there are no modifier. Likely someone has to come up with a gesture that makes sense?


map the buttons correctly depending on if there are 1, 2, or 3 buttons on the mouse
3 button mice RYB
2 button mice RBY
1 button mouse R

macintosh, if you hold the cmd/opt/control keys down and click we only think you have the control key down for mapping purposes
macintosh, although event logic does have the concept of left/right shift key & command key. some/many flavors of older powerbooks tied shift
and command key lines together so there was no way to determine if the left key or right key went down.

typedef struct sqKeyboardEvent
int type; unsigned int timeStamp; int charCode; int pressCode; int modifiers; int utf32Code; int reserved1; int windowIndex; } sqKeyboardEvent;

timeStamp is the ms clock ioMSecs()
charCode is the mac roman character value of the key pressed (key char), or a virtual key code (key up/down)
pressCode is
#define EventKeyChar 0
#define EventKeyDown 1
#define EventKeyUp 2
modifiers keyboard modifier state
utf32Code unicode 32 value (key char only), zero otherwise
windowIndex which window did the keyboard event go to

To complicate things, Tweak uses virtual key codes, but Squeak uses mac roman or more modern implementations like Sophie use uf32Code
Also due to the sub-standard Windows api utf32Code is only available on EventKeyChar not on key up or down which leads to the fun state where tweak platforms have to map key up virtual codes to the unicode value in order to make sense of what is being pressed.

Note the virtual key code is the concept on windows of having VK_SHIFT or VK_A which are magic numbers and if you know the decoder then well you can say Oh that magic number means "A" in whatever character set you are working with. On the macintosh the virtual key codes are the numbers assigned to keys on a keyboard, see:
So we can say the virtual key code of zero maps on usa keyboards to 'A'

Normally the process is
key down
key char
key up

But for Repeat key, again because of windows limitations the event situation for repeating key is
key down
key char
key down
key char
key up

To complicate things we track raw keyboard events and kEventTextInputUnicodeForKeyEvent so that we can report on the keys the
person used, but also then the resulting unicode since a unicode phrase might be generated by numerious keystrokes, or dead keys used
to create accented characters.

This complicated procedure borrowed code from the unix implementation where it records raw key down events, or key repeat events in a keymap, then on a raw key up it generates a EventKeyUp. Usually the key stroke key down, key up would then generate
record raw key down
see kEventTextInputUnicodeForKeyEvent
which would generate a
EventKeyDown using the macintosh virtual key code kEventParamKeyCode
EventKeyChar using the mac roman key value and the unicode value
EventKeyUp (MAYBE) using the macintosh virtual key code if this is a unicode phrase we are seeing due to dead key input logic
the raw key up
would generate a EventKeyUp if it mapped to a recorded raw key down

Note for wheel mouse we generate the key down/char/up for cursor keys

There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki