Posted by editor
on January 27, 2005 at 5:44 PM PST
OpenOffice.org for Mac OS X will keep its X11 dependency and apparently will never get a native Aqua look. The Java-assisted NeoOffice/J is already part-way there. What's the big picture?
Apparently, the native-looking Mac OS X version of OpenOffice.org is not going to happen , due to a variety of issues , the worst of which are technical in nature . An eWeek article takes a higher-level look at the situation and talks to the political issues hinted at by MacSlash, issues like use of resources and ownership/contribution of code.
For those who don't care to read all the links, here is the story in short. OpenOffice.org on Mac OS X is not an easy proposition because Mac OS X's windowing environment has little in common with X11, which is taken for granted on any other flavor of Unix. That meant that OO.o could be brought up in Mac OS X's optional X11 server (although it took a year just to get that to compile ), but that getting its data models wired up with Mac OS X's buttons and menus, working with OS X's events, font handling, etc. would be a much tougher proposition.
Interestingly, while a native binding proved too daunting, another approach worked out a lot better. NeoOffice/J forked off of OpenOffice and got to the native Mac UI space by way of Java. Note that that doesn't mean it's a port of OO.o to Java; rather, OpenOffice.org code runs natively under the covers and new NeoOffice/J provides the interaction with Aqua, the Mac's native UI. This means that things look and feel more right to the typical Mac user - the menu is on the top of the screen in the One True Menu Bar, it can copy-and-paste to and from other Mac applications, etc. Recent versions have added scroll-wheel and drag-and-drop support. It's a great piece of work.
Does this tell us anything we can take away for the next huge project? Here are a few thoughts to be kicked around. Use the talkbacks if you agree or disagree with some of the conclusions I'm proposing to draw.
- Early lock-in is deadly - How much do you care about porting your GUI inthe future, and what do you have to do to keep the door open? Sure, we hear about keeping models and views separate, but are you really going to create your own pseudo-GUI layer in between your model and the real GUI? Just throw in an X11-or-Windows switch, because that's all you're going to need, right? OTOH, didn't Mozilla build their own GUI layer? And is Java the pseudo-GUI layer for NeoOffice/J?
- Does this argue against the agile idea of building only what you need now and not building in features you don't need? - Even if OO.o had seen OSX coming in their early design stages, what would it have cost to design in a way to accommodate something as different as Aqua, or any arbitrary windowing system? Would it have been harder to get earlier versions out? That argues for the XP-and-friends idea of not building in features that you're not sure you'll ever need. But, does this story show that at some point you cross a point of no return where there's so much code with dependencies that it's impossible to rewrite/refactor in the change that you didn't design for? Personal story: I've been involved with two internationalization projects. In both cases, GUI applications were started with no internationalization concerns because the companies were in a Big Damn Hurry to throw some code out the door. Then they got some international customers, so they needed to I18N the code. We had to go through and identify all the places that needed I18N'ing, and rewrite it. In each case, after two weeks of work, the I18N effort was terminated by management because it was taking too long.
- Is there any other place that NeoOffice/J's approach could be applied? - Lots of people write apps without ever planning to do Mac or Linux versions. Heck, some companies I've worked for unapologetically wrote Windows-only Java applications. Is this a more general approach to port and run the data side of the application in the background, and then use Java (AWT, Swing, SWT) as a general-purpose way to get to the screen and the event-queue? NeoOffice/J's title screen, at least the last version I checked, described itself as "a prototype office suite exploring technologies for use in OpenOffice.org". Seems like the exploration has been well worth it... what's next?
Thoughts on these thoughts?