Mike Pinkerton wrote: > > > 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? > >
Since I dont really know that much about this stuff I dont know if I can make a judgement, but wouldn't it be good to go the cocoa way for the future. I mean plugins aren't going to be carbon for ever. Are they? Jeff
