Multiple OS Windows for Squeak?

Andreas Raab andreas.raab at gmx.de
Sat Apr 17 20:33:42 UTC 2004


> You certainly wouldn't need image _format_ changes for this. Image
> _code_ yes; quite a lot.

No, actually it isn't. If you look at the amount of C code which is involved
in window management it really isn't all that much and dealing with it on
the Squeak end would require no more than we're doing anyway (e.g., use a
few prims to fetch the events and draw some stuff). It's actually a fairly
minor effort to do this if you focus on the right aspects (but I will
acknowledge that it is *very* tempting to go beyound it and screw up
royally).

> The VM would need changes to stop keeping a
> single OS window as a special thing - in VW the window handles are kept
> in a broadly similar way to our file handles.

There is no need for the VM to stop keeping the single OS window as a
special thing. You would be able to get away from it at some point but you
might as well keep it for the time being.

> Someone managed to do it for OS/2 several years ago - search for
> 'Cheese'. IIRC that went quite a lot further than simply having
> multiple windows to include using various OS widgets in a manner not
> unlike the old PPS 'Van Gogh' project.

Yes and that is part of the reason why it never took off - there was too
much work involved and too little communication to make sure the
cross-platform aspects are dealt with accordingly.

> One could probably bind DisplayScreen objects to individual OS windows,
> change the vm to create them only when requested (RISC OS already does
> that for the current single Display) and mess around with the window
> updating to dig out the window identifier so as to get the right bits.

Bah... why bother? Wanna know how I think about this? Display should really
be an alias to whatever the host "display system" represents, (for example
the X-server on Linux) and when you draw to display you get something
looking like here:

http://www.impara.de/~andreas/sample.png

*Then* you create a window on that display and associate whatever kind of
drawing surface you want with it (or use the native graphics interface).
What you need to do this is a pretty small interface across the platforms
with the only "fast path" being the ability to throw bits to the display
surface (e.g., what we do today already).

> A Dire Warning - once you start on this path, be ready for demands for
> host OS widgets, fonts, menus, callbacks, transparent OS handles (and
> the problems of portability will make you tear your remaining hair out)

The only one I acknowledge from the above are fonts - those you have to be
able to deal with (the screenshot above uses the platform Comic Sans font)
but then again, there is no reason why you can't have both - host font
rendering as well as Squeak-internal text layout. It isn't exactly rocket
science to deal with this stuff you know ;-)

Cheers,
  - Andreas




More information about the Squeak-dev mailing list