On 30/10/01 6:43 pm, in article [EMAIL PROTECTED], "Mike Pinkerton" <[EMAIL PROTECTED]> wrote:
> [ ... ] > > My guess is that we can first port widget to Cocoa. GFX can stay as-is > because we can just put a NSQuickDrawView in the NSWindow and then gfx > can stay quickDraw based (just as a first step). Some things in > apprunner would have to change because we'd have to create an > NSApplication, but that's not a big deal. So, changes confined to xpfe/bootstrap/nsAppRunner.cpp? (Any temptation to use NSUserDefaults for registry goodies?) This is sounding doable! > Then we could work on replacing gfx with quartz or cocoa calls. Direct > quartz might map better to the gfx apis. > > None of this really impacts networking or layout as gfx/widget have been > fairly well abstracted from the rest of the app. We've actually done a > reasonable job of isolating native call sites. Looking even better... > The one problem is plugins. Since they assume Carbon, we have to have a > way to meld the carbon and cocoa event and drawing together within the > same content area. Omniweb does this by creating a Carbon window and > hacking a NSWindow around it. What about installing our own NSRunLoop (we can replace the one returned by currentRunLoop, perhaps)? (How do Carbon loadable bundles steal real-estate when in a cocoa environment?) > This kinda makes going the full cocoa route sorta pointless, no? Going the cocoa way gives the Java people an opportunity to get involved, yes? ian
