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'd need to do floating palettes as well, which luckily on most OSes 
now are supported natively (ie, nothing has to be done in the 
application other than set a flag)

Our real goal is to make people think TK4 is a Mac app like any other 
app.  cmd-m minimizes the front window, cmd-q quits, asking if the user 
wants to save their document, etc, etc.

We WILL succeed, even if Andreas cringes at the site of my emails by 
December.  :)

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/