Let me give a little background, that might help.
In the beginning, there was Mozilla. The widget and graphics layers were written with Quickdraw using all of the old Mac OS API calls. The app ran on OS8 and OS9.
Then Apple released Mac OS X and they wanted a whole bunch of apps to run on it with limited tweaking. They munged all the old APIs into a reduced set called "Carbon". These are mostly legacy APIs, C-based. Many of them have existed since 1984. Also "introduced" with OS X was a totally separate UI toolkit called "Cocoa" based on the NeXTStep objective-C toolkit, cleaned up and repurposed for OS X, called "Cocoa". These toolkits live independently for the most part.
In order to run on OS X, we had to "Carbonize" Mac Mozilla. This effort, which I led, was called "Fizzilla" (cuz it's carbonated, get it? didn't think so) and resulted in a CFM-based version of Mozilla that ran on both OS9 and OSX, though we only really ever certified it for OSX. Fizzilla used all the Carbon APIs which were the same Quickdraw, etc APIs that have been around on the Mac forever. The original Fizzilla was still built with CodeWarrior.
After the Fizzilla port was complete, we realized that we wanted to ditch all the file, threading, and networking code using the old antiquated MacOS apis and use the much more performant and easier to understand UNIX apis. In order to do this, our app had to use the mach-o binary format, which also had other speed benefits. To separate the two projects (CFM v Mach) we reused the names slightly: Fizzilla became "FizzillaCFM" and we introduced "FizzillaMach".
FizzillaMach only ran on OSX and was built using gcc and the same make-based system the other UNIXes used, which was a HUGE benefit for the dev community. It also moved from pay tools (CodeWarrior) to free tools (gcc) which got another big cheer from the open source community. FizzillaCFM was eventually retired completely, I think the last version of Mozilla that was CFM was Moz1.4.
After we completed that transition, I and a few others started to get interested in Cocoa development. We already had a Carbon-based embedding layer (written by Conrad Carlen) using Metrowerk's Powerplant. Several companies used it to embed mozilla in their CFM apps. For mach-o, though, we had no embedding solution and if mach-o was our future, we needed to make something happen. We could try to use PP in a mach-o world or we could try to use Cocoa which apple was pushing very heavily over Carbon as the future api for MacOS.
As I recounted in my ArsTechnica interview, Vidur and I created an embedding layer that wrapped mozilla in Cocoa, allowing its use from any Cocoa app. We also rewrote certain parts of widget with Cocoa instead of Carbon. Thus, "Cocoazilla" was born. CHBrowserView, formerly NSBrowserView, was the embedding-layer API most visible to embedding apps, so the two became synonymous in their usage. CHBrowserView, however, isn't a project name, it's a NSView subclass only. The goal of Cocoazilla was to write as much of widget and gfx with cocoa implementations and then eventually move all of Mozilla over to those. Obviously that is still in progress ;)
Camino (then Chimera) picked up on Cocoazilla and took it to a new level. We were a Cocoa front end and embedded Gecko through CHBrowserView. Why are there two CHBrowserView's? Blame hyatt. He was too lazy to use the embedding layer correctly and forked it. We've never gone back. The CHBrowserView in the mozilla tree has probably bit-rotted and may or may not be usable. Camino has its own version that is conceptually similar but is kept up to date with a tinderbox to monitor Gecko API changes.
Anything I leave out? -Pink
_______________________________________________ Camino mailing list [EMAIL PROTECTED] http://mozdev.org/mailman/listinfo/camino
