OpenOffice/NeoOffice on Mac OS X
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.
Oct. 03, 2002 11:36 AM
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
Phase 2: Wean it away from X11. (Get it to run without an X
Phase 3: Adopt Aqua look and feel. (Make it behave like a Mac
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
Spaces in filenames and paths created problems
Apple's gcc2.95.2 based compilers are finicky--use gcc3 if
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
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
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,
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.
is the founder and CEO of O’Reilly Media Inc. Considered by many to be the best computer book publisher in the world, O'Reilly Media also hosts conferences on technology topics, including the O'Reilly Open Source Convention, Strata: The Business of Data, the Velocity Conference on Web Performance and Operations, and many others. 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 is also a partner at O'Reilly AlphaTech Ventures, O'Reilly's early stage venture firm, and is on the board of Safari Books Online, PeerJ, Code for America, and Maker Media, which was recently spun out from O'Reilly Media. Maker Media's Maker Faire has been compared to the West Coast Computer Faire, which launched the personal computer revolution.
Showing messages 1 through 3 of 3.
Aqua is here!
Showing messages 1 through 3 of 3.
Return to weblogs.oreilly.com.
Weblog authors are solely responsible for the content
and accuracy of their weblogs, including opinions they
express, and O'Reilly Media, Inc., disclaims any and
all liabililty for that content, its accuracy, and
opinions it may contain.
This work is licensed under a
Creative Commons License.