SqueakEnvironment, or the "low road" to native GUI

Marcel Weiher 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.

To do:

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 mailing list