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.

- Doug


>
> Steve
>
> 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 
>> 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
>>
>>
>>
>>
>
> http://www.geeksrus.com/
>
>