Rushi: As was mentioned by Nick, the native appearance of Firefox 3 is faked since it still uses XUL at its core. Some people don’t notice, but the longer you use a Mac the more you begin to notice the difference between faked and truly native. The best I can say is, try it for yourself. :)

pwb: I’m sorry you feel that way, but the goal of the Camino Project is separate of the goal of Firefox. Mac developers interested in Camino often write Obj-C and don’t wish to program in XUL, JS, and C++ to hack on the browser. Switching all Camino developers to Firefox development wouldn’t work and many developers wouldn’t even use Firefox (much less develop for it) if Camino didn’t exist.

Fx3: We intend to use Gecko 1.9 in the next major release of Camino (Camino 2), but it wasn’t even close to stable when development started for Camino 1.6. The work done for Gecko 1.9 is largely Firefox-focused and means we won’t immediately have a solid base to work on. Development work is migrating to trunk (Gecko 1.9) where we’ll begin to fix problems that hinder development of an embedded browser (Camino is considered “embedded” on top of Gecko, as opposed to Firefox).

zahadum: I’m not entirely sure what you mean by your #1. Netscape developers live on throughout the industry, at the Mozilla Corporation, the Camino Project, Songbird, Flock, etc. Calling them all “deadwood” isn’t fair and is very much trolling. For #2: The “mainline” Firefox “release” right now is Firefox 2.0.0.14. I would know; I just helped ship it. Firefox 3 is still in development and isn’t ready for general users. When it is, then you can compare them, but as I stated above, Camino made explicit choices about what Gecko release we’d be working on top of. For #3: “refuse” is a harsh word here. Have you filed feature requests so new features can be considered? I haven’t seen any. For #4: I haven’t seen very much end-user confusion. Please point me towards it and I’ll be happy to clear it up. For #5: Again, if there are specific feature requests you have, please file bugs and we’ll consider them all individually. For #6: Most Camino developers don’t want to work in XUL, so they don’t. A project like “building cocoa bindings for xul” is immensely huge and isn’t something an all-volunteer team is likely to do.

Kevin-J: Tab drag and drop is coming in a future release (hopefully Camino 2). It almost made 1.6 but had to get parts rewritten.

–

I do appreciate the comments and am more than willing to answer questions people have. Thanks for the shout out, Om!

I don’t see any Firefox releases with anything newer than Gecko 1.8, just betas. You think Camino 1.6 should have used an unfinished rendering engine that isn’t even ready to ship in Firefox yet?

Kevin,

the worst typo is obviously in example 2 ….

“when i search my bookmarks, i should be [[[not]]] obtain a result for a term”

• obviously ;-)

sorry for the other typos.

a decade on, they STILL have not learned the fundamentals of software engineering (UML) or the tao of mac design.

2) they rendering engine is more than a year obsolete compared to the mainline ffox release …

3) they refuse to add value to the mac browsing experience by developing tools for the semantic web that would leap-frog over the gecko engine issue.

there is no advanced RDF::query languages / or KIF / or OIL+DAML …. nothing useful at all for a nexgen experience.

4) they cant even sort out the (end-user) confusion about how their UI charter for cocoa-on-top-of-gecko differs from ffox’s new cocoa-widgets-on-top-of-xul (?)-on-top-of-gecko.

5) camino had the opportunity to fill the void left by apple’s safari re the semantic web … but it chose instead to worry about cosmetic trivialities of UI widgets (though keychain & spotlight are essential improvements over ffox) instead of dealing with the heavy lifting of // core functionality // … which means semantic web.

example 1: if i tag a bookmark (opps, i forgot: camino doesnt support tags yet even though ffox does) with term X, then later on when i do a search using term Y camino should be able to return a result that inlcudes terms in set Z that are RELATED to /both/ x and y … in other words, my bookmark manager should be able to support inferences about the relation between term X & term Y (eg ‘cats’ and ‘animal licensees’) … the questor (ie the user making a query) should NOT have to build & retain an ever-increasing mental model (a taxonomy) of the meaning of all the terms in a document – and the relations of all those terms – so that he can be an effective tagger!

The job of, in effect, implicitly tagging one term with other related terms should be a core part of the user experience of the platform not a manual activity for the user. DATA ENTRY (ie tagging & markup) is a semi-clerical task — but computers were supposed to eliminate that procedure …. however do to lazy support for the semantic web standards from the W3C (yahoo is a recent exceptiion) all of the major platfoms ignore KIF, OIL+DAML, and all the other RDF infrastructure necessary for the web to catch up & join the 21st century!

example 2: when i search my bookmarks, i should be not obtain a result for a term even if it is not implied inside other documents which i have also tagged with a similar term — the links inside the documents i have bookmarked should also be searched for a match.

example 3: when i make a bookmark, i should be able know how that url is used/rated/tagged by anyone within my circle of trust (ie RSS meets SNS) … ie the bookmark manager needs to have service discovery for my buddy list (x500/x509 needs to be extended to support non-terminal attributes) … andan intelligent bookmark/history manager needs to have a new UI that allows for simple & quick visualizations of these spatialized relations in psudo3D – eg hyperbolic trees.

This kind of charter for smart documents is the only plausible rationale for why a mozilla browser on the mac should exist: ie to add value to the commodity (rendering) story, by creating a platform that is ready for information abstraction —- recall that the mac’s original franchise was create a (better) abstraction of the system level objects; since apple refuses to do anything serious with cocoa about knowledge management, then the logical progression for a third party, like camino, is to get beyond trivial issues of re-skinning the UI of ffox, and instead deliver what mac users inherently care about: which is good, useful & elegant abstractions … in this case, of content).

6) i agree with the many of the other posters: the camino team is always a day late & a dollar short — if they cant do anything serious (semantic web) then they should at least focus creating a real/non-trivial mozilla hybrid by building cocoa bindings for xul (so that xul plugins from ffox work) … remember that zul implementations are supposed to be language independent:: so PROVE it!

story bookmarked @ http://livbit.com

Several times I’ve strayed (first Safari, then Firefox, then Flock for a brief time).

I keep coming back to Camino for my workhorse, day-to-day browser.

One of the most Mac-like apps ever (which imho is hilarious given that Apple makes Safari).

Camino 1.6 still uses the old Gecko 1.8 engine, same as Firefox 2.0, so it has all the problems of Firefox 2.0.

Firefox simply doesn’t have the speed on older Macs. Firefox on my MacBook Pro is certainly much faster but when I install Firebug and a few other extensions it starts to get slow. Not terribly sow but definitely slower, which is a trade-off I accept for the usefulness of such extensions.

What do you get for losing features and flexibility? A native Cocoa user interface.

BFD.