Instances of WindowEvent are created for every event coming from the graphics device.
Usually, they are enqueued by the event dispatcher process into
a sensors input queue, and dequeued & processed by a windowGroup process
in its event loop.
WindowEvents hold the event type and additional information (such as key,
x/y coordinates etc). Also, windowEvents know how to send themself to some
destination. To provide a common (single) place where event dispatching is
implemented, this forwarding is done by a class method here (i.e. not by the
window group itself).
The algorithm for event dispatching is:
- if the destination view has a keyboard focus set,
AND the event is a keyboard event,
THEN recursively invoke the event dispatching method,
sending the event to the focus view (or its delegate, as below)
- if the destination view has a delegate,
AND its a keyboard, button or pointer event,
AND the delegate is interested in that event
(i.e. implements & responds to #handlesXXX with true)
THEN send the event to the delegate, passing the original view
as additional argument
- if the view has a nonNil controller,
AND its a key, button or pointer event,
THEN send the event to the controller
- otherwise send the event to the view
If the view has a non-nil transformation, the event is sent as a
#deviceXXX message, passing device coordinates. Typically, subclasses
of view do not redefine this method and the inherited default method
translates these device coordinates into logical coordinates and resends
an XXX message.
If the view has no transformation, the XXX message is directly sent here.
For example, a 'buttonPress:button x:x y:y' event leads to sending of
'aView deviceButtonPress:button x:x y:y' which resends
'aView buttonPress:button x:(x-logical) y:(y-logical)'
This allows views which are interested in deviceCoordinates to get them
(by redefining #deviceXXX) and other views to transparently get & use
logical coordinates.
Therefore, for a delegated keyPress messages, the flow is:
sendEvent
view has delegate
------> ask delegate via 'handlesKeyPress:key inView:view'
<------ returns true
------> 'delegate keyPress:key x:x y:y view:view'
-----> delegate does whatever it wants to do
(typically sends the event to some other view)
for an undelegated message:
sendEvent
view has delegate
------> ask delegate via 'handlesKeyPress:key inView:view'
<------ returns false
view has controller
------> 'controller keyPress:key x:x y:y'
view has no controller
view has transformation
----> 'view deviceKeyPress:key x:x y:y'
inverse transform x/y
----> 'self keyPress:key x:xLogical y:yLogical'
view has no transformation
----> 'view keyPress:key x:x y:y'

Compatibility
append a printed desription on some stream (Dolphin, Squeak)
OR:
display the receiver in a graphicsContext at 0@0 (ST80).
This method allows for any object to be displayed in some view
(although the fallBack is to display its printString ...)

return the view which will eventually handle the event;
for most events, this is the same as the view, for which the event was
originally generated.
Except, if an explicit focus has been assigned (i.e. tabbed into a component),
AND the event is a keyboard event. In this case, the targetView might be different.
Notice: this method might return nil, for synthetic (app-related) or display screen related
events