"Andreas Raab" <andreas.raab at gmx.de> 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).
I'd be delighted to be proven wrong - though I truly think you're
underestimating the effort.

> 
> > 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.
Nothing wrong with keeping a single main window as special but as John
points out you need to have the update window type routines able to
handle many windows instead of assuming The One True.


> > 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).
Very cool idea - tell us more. One thing that bothers me about the idea
is that (remembering ancient NT related stuff) some OS's don't want you
to be able to read or write over the whole screen for security reasons
or wotnot. NT for example claimed you couldn't do the old ObjectWorks
tpye window opening with a marquee because it violated their C2
security.

> 
> > 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.
Not sure I follow you here. You only acknowledge that people will ask
for fonts, or that they're the only ones difficult? Of course the good
thing about a project like Squeak is that unreasonable people can demand
all they like and we can just ignore them until they go away and use VB.


> It isn't exactly rocket
> science to deal with this stuff you know ;-)
If only it were that simple.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
I do not fear computers.  I fear the lack of them.  - Isaac Asimov