Firefox 3 for Mac OS X: Under the Hood
The context menus, dropdown menus, the toolbar, the search bar, the buttons and text fields within Web pages—they are not actual Cocoa controls. For example, instead of using actual Cocoa buttons for “Submit” buttons we just draw the image of an Aqua “Submit” button into an NSView, one of the basic Cocoa objects we use. Gecko 1.9 has Aqua form controls because we now draw images of Aqua form controls when appropriate, not because we use actual Cocoa controls. The reason we don’t use actual Cocoa controls isn’t because we are lazy or we can’t figure out how to use them or because we are constrained by our cross-platform requirements—Apple’s WebKit doesn’t use actual Cocoa controls for things like “Submit” buttons or popup buttons in Web pages either, at least not the last time I checked.
Sure, but Firefox 3 also uses the fake controls throughout the application: the preferences window, the browser toolbar, the bookmarks editor, etc. Even without clicking on anything, it’s obvious that the interface was built using a cross-platform framework.
Update: Johan Sanneblad has screenshots of some of the differences (via John Gruber).
6 Comments RSS · Twitter
I don't follow your logic here. If it uses Cocoa API's for the drawing primitives, how can it be "fake"? My definition of "native GUI" is anything that uses a Mac-specific/Mac-only API for the GUI--this could be either Carbon or Cocoa. Perhaps this definition is too generous?
In any event, Firefox 3.0 is very nice to use--a big improvement over 2.0. I certainly consider it much more "native" than previous iterations, and I would attribute that to its use of Cocoa.
Not to mention they don't know how to follow basic aqua guidelines. Not only do they fake the toolbar in the preferences window, they go out of their way to fake the "lozenge" button in the top-right, which is completely unnecessary for a prefs window.
Kevin Walzer: Native would be using an actual NSTextField or NSToolbar (or Carbon equivalent). Fake is drawing a bunch of pixels into a plain NSView so that it looks like a text field or toolbar. It doesn't matter much what drawing primitives they use if they're going to fake it. By your definition, just about everything would be native, because aside from some games that use OpenGL, just about all the cross-platform toolkits (Qt, Java, Tcl/Tk, etc.) use Carbon or Cocoa drawing primitives at some level. And they don't look or feel right, either.
I agree that Firefox 3 looks better than Firefox 2, but almost every single control they uses still looks or behaves differently from the native ones. Seriously: text fields, pop-up menus, help buttons, toolbars, tabs, separator lines, table views, sheets, the list goes on. The about box has the same non-functional lozenge in 3 as in 2. The help buttons actually looked closer to being native in Firefox 2.
It's not enough to use Carbon or Cocoa windowing API's; otherwise every crappy Java port could be called a Cocoa application, because Apple's implementation of Swing is built on top of Cocoa. But I also don't believe that you must use only NSFoo calls in your code for it to be a native application. NeoOffice uses Java but gets the Mac details right. Adobe InDesign and Dreamweaver feel native, at least to me, and they are Carbon. Parallels is a Qt application but gets the Mac details (look and feel) right, in my opinion. Office 2008 also does a good job here.
Perhaps I'm equating "native" with "good Aqua HIG compliance." Cocoa makes that easier, but it's not the only way to get there. A well-designed API that sits on top of Cocoa (or Carbon) can do this as well. That's one reason to use cross-platform toolkits, even if you are just doing Mac development; I find that, for me, Tk provides a more elegant and intuitive API than Cocoa. Believe me, I sweat the HIG details in my apps, and I think they are worthy of the term "native." I also believe that Firefox 3 does a good job.
To each their own.
Kevin: I guess you're looking at different details, because none of the ones that you mention feel fully native to me. InDesign and Office 2008 are pretty good, but clearly have cross-platform influences. Parallels is somewhere in the middle. NeoOffice isn't even close to looking native. Interarchy is a Carbon app that I'd say feels fully native and modern.
No offense intended, but it's obvious just from the screenshots that your apps don't use the native controls. I downloaded PortAuthority, and there are numerous violations of the letter of the HIG (for example no Window menu and the control spacing in the preferences window). And there are lots of details that the HIG doesn't necessarily cover, but which are accepted Mac guidelines. For example, a preferences window should not be modal and should not have a save button. Standard keyboard shortcuts shouldn't be repurposed (Command-S should be Save, not Port Information). Inapplicable commands should not present an error, but rather should be disabled in the menu.
This isn't to say that any of the above are bad apps. But, purely as a factual matter, one could create a long list of appearances and behaviors that deviate from what you would get using the native Carbon/Cocoa controls and following longstanding Mac interface guidelines and conventions.
Re: PortAuthority, it's true that it uses Tk widgets. The search field is a stylized ttk::entry widget, not NSSearchField. The treeview is BWidget::Tree, configured with disclosure arrows instead of the +/- image. The table view is tablelist::tablelist,'s ttk variant, not NSTableView. And the text view is tk::text, not NSText. The toolbar is my own concoction, a megawidget called mactoolbar::mactoolbar (ttk::frame, ttk::labels, and images styled to emulate the behavior of NSToolbar depending on what events fire).
I don't take any offense about its variations from the HIG. The window menu is easy to fix, and the preferences window can be cleaned up too. Thanks for the feedback.
I've thought long and hard about the business case for rewriting it in Cocoa. It's my best-selling program, and sales have remained steady even in the wake of a free Cocoa competitor, Porticus; I was afraid that Porticus would cause my sales to tank. Regardless, PortAuthority is a lot more HIG-compliant and clean-looking than it used to be, and users have given me positive feedback on that. Given all these factors, it's hard to justify the time and learning curve involved in learning Cocoa. I'm just not sure it would lead to more sales.
