"Andreas Raab" <andreas.raab at gmx.de> wrote:

> I truly think you're wrong here ;-)
Well, good. I have to be wrong occasionally.  My scepticism is based on
being involved in two or maybe three projects to do similar stuff at
PPS. All showed early promise, all had smart people working on them and
all turned into problems. But you're definitely right to say that our
needs are simpler and it may be enough to make it practical.

> Let's see ... two areas we need to fix:
> a) We can't rely on implicit updates of the window after BitBlt (or at least
> not easily at this point)
No? Surely since we know what bitmap we are blitting to (at least I
sure hope we do!) then we can find out which OS window it corresponds
to. If ioShowDisplay were extended to pass a window Id it ought to work
out quite simply.

> but that's essentially equivalent to
> #forceToScreen: which we have in the bag already
Didn't follow that one, sadly. Besides, we recently discussed
forceToScreen et al. and concluded that it was a no-op on Windows.

> and b) we need to pass up
> invalidation events since we can't any longer rely on other windows being
> updated via fullDisplayUpdate() implicitly.
Well fullDisplayUpdate isn't even used by some platforms so clearly it
can't be relied upon :) At least on RISC OS, invalidating the
appropriate windows/areas will result in incoming events requesting the
redisplay so I don't see any problem. I'm sure we could work _that_
part out ok.

> But besides this ... what else
> do we need? We could still route the events via the single vm event queue
> (just associate a window ID with the event - I quite deliberately left room
> for those in the event structure ;-) and dispatch accordingly. Add
> primitives for:
> a) window creation/destroy
+ add various flags for type of window, cf use for menus etc, plus
dialogues 
> b) window manipulation (visibility, position, size...)
+ z order, focus (?)
> c) window display
+ hide
> and we're done here.
> Really, if I weren't busy with other stuff I'd pull out some code which did
> almost all of the above and fix it to get it to a working demo. I still have
> it somewhere and trust me it wasn't much.
Oh, I believe you. But even if it was 80% of the solution, the other
20% would take 80% of the time... 


> it seems to me that the important part really is to use a carefully
> defined set of abstractions which can be supported cross-platform as well as
> emulated in reasonable ways.
That was almost exactly the phrase used when establishing the Van Gogh
project at PPS. Good aim, with plausible solutions (bridge patterns for
example) but there were still terrible problems. It was a much more
ambitious undertaking though, so perhaps the inevitable scepticism
stemming from "been there, done that" can be proven wrong. I do hope
so. 


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Managing programmers is like herding cats.