Stefan Matthias Aust
sma at kiel.netsurf.de
Mon Sep 7 13:26:26 UTC 1998
>Personally, I think the best solution would be to go to an event
>driven model. The basic problem is polling, events would take
>care of it.
Interesting idea. How could this be done?
Let's assume an architecture, that uses "widget" objects and "model"
objects. A widget is the combination of view and controller. As the view,
it's a dependent of the model. Widgets will react to events, implementing
The list of possible events should contain at least:
Mouse cursor was moved (position x,y)
Mouse button was pressed (button state, modifier state)
Mouse button was released (button state, modifier state)
Key was typed (key code, modifier state)
These system events might also be useful:
System attributes have changed (fonts/colors/screen resolution)
Screen close request (user/system)
Then, either we double buffer screen display, or we also handle:
Screen damage repaint request (rectangle)
If we allow more than one "Squeak screen" aka host window:
Window close request
Window got focus
Window lost focus
Window damage repaint request (rectangle)
But let's concentrate on the first four events for now. There should be a
"get event" primitive, which answers an array containing the event number
and all aditional parameters (also integers if possible).
A system event dispatcher will retrieve these VM events, process and
dispatch them. It'll listen to all movement events, determining the active
window widget, sending a "mouse entered" to that widget. It's now the
responsibilty of the window widget to react. The window might register
itself as the active window. Key events are always forwared to the active
window (if there's one). The window will then forward the key to the widget
which currently has the focus.
This has to be detailed, but it seems to be strait forward.
But how to deal with concurrent processes? Any ideas?
Stefan Matthias Aust // Are you ready to discover the twilight zone?
More information about the Squeak-dev