Ian Wilkinson wrote:
> what would represent a minimum to afford basic rendering > (so, minimum Cocoa imaging and controls)? > How will Core Graphics Rendering effect existing printing. > Will the introduction of Cocoa seriously impact other services? > Is existing mac event machinery confined to widget, or is > knowledge required by other services, for example, does > nsMacMessage... influence netwerk behaviour? 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. 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. 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. This kinda makes going the full cocoa route sorta pointless, no? -- Mike Pinkerton Mac Browser Weenie [EMAIL PROTECTED] http://people.netscape.com/pinkerton
