Multiple OS Windows for Squeak?
dway at mailcan.com
Tue Apr 20 16:22:55 UTC 2004
Steven Riggins wrote:
> And as Andreas knows, TK4 *must* have multiple OS windows or we're
> dead in the water. I'm glad to see others needing this as well, and
> we should all stay in the loop and share our work in this area to see
> if everyone can benefit.
> We WILL succeed, even if Andreas cringes at the site of my emails by
> December. :)
Sounds great! So, do you want to spearhead this effort? :-) It would
be great to have multiple OS window support in Squeak. All it takes is
a sufficiently motivated person with *some* of the appropriate
expertise... the rest of the expertise is waiting for you on this list
if you ask questions.
> On Apr 17, 2004, at 1:33 PM, Andreas Raab wrote:
>>> 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
>> 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
>> 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
>>> 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
>> be an alias to whatever the host "display system" represents, (for
>> the X-server on Linux) and when you draw to display you get something
>> looking like here:
>> *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
>> 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
>> 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
>> science to deal with this stuff you know ;-)
>> - Andreas
More information about the Squeak-dev