SqueakEnvironment, or the "low road" to native GUI
marcel at system.de
Thu Feb 18 12:47:53 UTC 1999
I think there are 5 distinct levels of native GUI integration:
1. Blitting into a native window
2. Opening new native windows
3. Drawing using native facilities
4. Native event reception
5. Fully native widgets
(1) is done by any Squeak port with a GUI, it's part of the VM.
However, there is an implicit global window. This routine would have
to be modified to include some sort of native window handle in order
to support blitting into newly opened native windows.
(2) shouldn't be too hard with pluggable primitives, the only issue
is actually drawing into them. For MVC this could be handled using
the VM mod outlined above, but Morphic makes it even easier (see 3).
(3) With Morphic, native drawing essentially means creating a custom
canvas class that turns the morphic drawing protocol into native
calls. If each Morph is sent to the current canvas for drawing (
something along the lines of fullDrawOn:aCanvas -> aCanvas
drawMorphAndSubMorphs:self ), it would be trivially easy for a native
Canvas to detect top-level window morphs and redirect their content
drawing into a native window. Squeak-centric drawing would be
unaffected except for a couple of additional hooks. All that would
be necessary is for top-level windows to identify themselves to the
canvas. The current Canvas implementations don't need to do anything
special, they handle top-level windows just the way they do now.
(4) is present in a rudimentary form, with a polling native
interface and an event-based interface (in morphic) implemented on
top of that. All that's really needed is a hook to disconnect the
event-based interface from the polling-based one and let it talk
directly to OS event sources.
(5) I am guessing that with good-looking morphic widgets drawn in
native windows and event-based I/O, the need/desire for actual native
widgets will drastically decline. However, there could also be
hooks for providing native widgets.
The various hooks need to be fleshed out and gathered in a central
place, a SqueakEnvironment class or some-such. The SqueakEnvironment
class acts as an abstract factory for: - windows, default-canvases,
event-sources as well as InputSensors and possibly (at a later
stage) various widgets.
At first, the facilities gathered into the SqueakEnvironment are the
existing ones, no change in functionality (a classic refactoring).
Once that is in place, people can start working on various
Does that seem workable?
More information about the Squeak-dev