Revision [306]
This is an old revision of ioGetNextEvent made by JohnMcIntosh on 2008-10-21 08:12:24.
sqInt ioGetNextEvent( sqInputEvent *evt)
Parms:
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
Why:
To get FIFO UI event data from the UI
Responsibility:
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
MacIntosh
os-9/OSXCarbon
ioProcessEvents is always called.
Cocoa:
TBD
iPhone
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.
Unix
IF there are no events it calls ioProcessEvents, otherwise return next event on queue. Queue is not locked
Windows
IF there are no events it calls ioProcessEvents, otherwise return next event on queue. Queue is not locked
BUGS
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;
where
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.
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.
MacIntosh
os-9/OSXCarbon
On the macintosh 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.
Cocoa:
TBD
iPhone
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,up events. There is no concent
Unix
Windows
BUGS
