O'Reilly Network    

 Published on The O'Reilly Network (http://www.oreillynet.com/)
 http://www.oreillynet.com/pub/wlg/2097

OpenOffice/NeoOffice on Mac OS X

by Tim O'Reilly
Oct. 3, 2002

Today, at the Mac OS X Conference, in a session entitled "Porting Large Applications to Aqua", Ed Peterlin of openoffice.org spoke about his experience porting OpenOffice to Mac OS X. This blog is a running capture of his presentation; most of the words are more or less his, but any errors are my own.

Open Office contains 7.5 million lines of code, and produces 240 megabytes of executable code. It isn't just a large project; it's a huge project.

Before you start porting something like this, you have to ask yourself what kind of programmers you have. Old mac coders may not know Unix, and vice versa. You need both. And you have to ask yourself about your users. Do they want something with typical Mac "fit and finish"?

There was a three stage porting approach:

Phase 1: Get it to compile. (Just treat Mac OS X as another Unix)
Phase 2: Wean it away from X11. (Get it to run without an X server.)
Phase 3: Adopt Aqua look and feel. (Make it behave like a Mac application.)

Phase 1 (just getting it to compile) took a whole year. Key differences between BSD and Mac OS X that got in the way:

  • Shared libraries end in .dylib, and not .so
  • dl* routines are not used for shared library loading
  • there was missing or incomplete BSD functionality (10.2 is better)
  • Spaces in filenames and paths created problems
  • Apple's gcc2.95.2 based compilers are finicky--use gcc3 if possible
  • Not all X servers are created equal
  • Mac OS X is evolving, so we had to keep up with changes to tool behavior and interfaces, and not depend on undocumented features.

    Next week, public beta of the X11 release for Darwin 6, Mac OS X 10.2. It's not available for download till next week, but Ed gave out CDs to attendees of the session.

    It works, but is it done? It still has Unix interface conventions, poor connectivity with other Mac OS X apps, sluggish user interface. There's a lot more to be done to create helpful installers and launchers to keep novices away from the shell and provide extension mapping for the Finder. Good Mac applications adopt the Aqua Human Interface Guidelines, they leverage Mac OS X specific technologies, and interact well with other Mac OS X applications.

    Figuring out how to get there is the next challenge. Options:

  • Reimplement the UI from scratch in Cocoa - works best for applications with involved backends and refactored front ends. No clear separation here.
  • Use a portable widget set with an Aqua look and feel - Qt, Tk, Swing,...
  • Rewrite the core graphics layer

    OpenOffice.org has a significant amount of user interface code and user documentation, making a full rewrite difficult. the existing graphics structure is broken into layers.

    The chosen approach: port the core graphics layer.

    The result: it still looks like Windows, but it no longer requires X11 to run. Why is this better? Users don't need to worry about installing X, performance is improved, etc. But it still can be better. Controls are still drawn looking like X11 style controls. It looks like a Unix app, not a Mac OS X app. To get that far, you need to rethink the whole UI. Use Aqua controls, high quality icons, adopting sheets and drawers, remove modality, etc.

    Getting the look first -- if you take the approach of using a cross platform widget set, you may already have the Aqua look, but if you port the graphics layer first, you then need to port the widgets as well.

    The alternative is to use native controls directly. The feasibility depends on the event handling and interaction between widgets. So what we do is use native calls to draw the controls, but do event handling and state changes in platform independent widget code. This gets the program closer to the Aqua look, adapts to changes in aqua, and there's no change in how the widgets need to be used by other UI code.

    The Appearance Manager provides functions to render controls and parts of controls without needing to instantiate a full native control. This allows widgets to be accessed from the platform independent graphics layer through introducitng new calls, if we retool the widgets to use these routines when running on Mac OS X. The resulting code isn't pretty, but it works. And the users don't care how the code looks.

    More work remains, but the fact is, we've been able to make enormous progress with just 2-3 people. It does seem possible to undertake large Unix porting projects with involve user interface and adapt them to Mac OS X. We have to finish adapting complex controls to Aqua, and

    To find out more, go to mac.openoffice.org. Drop by to help us finish the Aqua port, help us test this out, find out more about detailed porting strategies and platform pitfalls, and examine the source code to help you in your own porting efforts.

    Tim O'Reilly is the founder and CEO of O'Reilly Media, Inc., thought by many to be the best computer book publisher in the world. In addition to Foo Camps ("Friends of O'Reilly" Camps, which gave rise to the "un-conference" movement), O'Reilly Media also hosts conferences on technology topics, including the Web 2.0 Summit, the Web 2.0 Expo, the O'Reilly Open Source Convention, the Gov 2.0 Summit, and the Gov 2.0 Expo. Tim's blog, the O'Reilly Radar, "watches the alpha geeks" to determine emerging technology trends, and serves as a platform for advocacy about issues of importance to the technical community. Tim's long-term vision for his company is to change the world by spreading the knowledge of innovators. In addition to O'Reilly Media, Tim is a founder of Safari Books Online, a pioneering subscription service for accessing books online, and O'Reilly AlphaTech Ventures, an early-stage venture firm.

    oreillynet.com Copyright © 2006 O'Reilly Media, Inc.