Steven,

>
> What if you don't want native widgets, but you do want native windows
> and window frames? I believe users will be thrown a little bit by having
> a bunch of entities that look just like application windows, but
> actually are not ("why can't I minimize it to the application dock, why
> can't I alt-tab to it?"). However, I *don't* believe users will be
> thrown by widgets like buttons or comboboxes that look just like OS
> ones, but actually are not.
>

Native window frames only, straightforward. Depends on the OS by what name
you talk about it, but you basically have to keep track of which graphics
context that you're drawing into [Andreas has massaged BitBlt over the years
so that you can blit different graphic contexts easily]. You  would cleverly
rewrite SystemWindow to handle all of this correctly. There are a couple of
events you need to keep track a little more diligently, such as window
activate/deactivate events. In addition, you have to sort through the mouse
and keyboard events and determine what goes where. In a simple
implementation conceptually there isn't one "top World" anymore, there can
be several.

In a simple implementation, the VM validates events and tells you where the
event should be headed and puts it into the event queue (i.e. attaches the
windowID/HDC/GrafPort what ever you want to call it to the event), and the
image dispatches the event accordingly. I recall that when I did this for
the Mac several years ago the most confusing part for me was keeping track
of global/local point conversions. Mostly book keeping type of code, and a
little bit of horror at the end trying to catch rogue code that doesn't play
by the rules.

I'll conveniently leave out dialog boxes, which in general need callback
capabilities. You can simulate most of their behaviour with a regular
window, or you might try slanging 'em in if *really* needed.


> Are callbacks required, say, for implementing a modeless child window as
> an OS window containing a Morphic world?
>

Nope, at least in the couple of OSs that I follow. This is all very
straightforward, you can do most of this with only a little effort. You can
create the extra windows with FFI calls currently (up in the image), you
only need to fiddle with the event queue in the VM a little to get started.
At some point, you need to draw the line of what gets processed where.

However, another sticky point comes up soon after. That is, you've provided
native windows, the use expects to be able to

A) have standard OS menus
B) have standard OS keystrokes work

On Windows & *nix you can probably come close to simulating that. On the
Mac, you're probably in trouble without some sort of native menu bar
implementation.

Jim