Slashdot Mirror
Sun Joins Mac Open Office Development
widhalmt writes "In a blog post, a developer at Sun Microsystems announces that Sun will help with porting Open Office to Mac OS X. The open source office suite is well known on Linux and Windows, but does not have a native version on Mac OS. For a long time Sun did not want to join the development of that port but now they will actively push it."
OpenOffice.org runs on Mac OS X under X11.
NeoOffice is an independently developed version of OpenOffice.org 2.1 which runs on Mac OS X natively and without the need for X11. I've been using it for years.
The OpenOffice developers doing the porting should send an email to Steve Jobs asking him to help end this outrageous and inexcusable incompatibility issue. It worked for Greenpeace and J. Maynard Gelinas!
First we get news that Microsoft was recently acting all Mac Happy, and now Sun is acting Mac Happy. My, my, my, but these coincidences of timing in the software world never cease to boggle the mind!
Okay, I got Linux installed. So where's the free beer everyone keeps talking about??
...that it's a Java application. Sun is pushing for a non-Java, non-X11 native solution. I like NeoOffice as well and it has replaced Office 2004 for quite some time for me, but it would be nice to get the Java part out of the mix.
Serving time in Aristotelean prison for violating laws of physics
Sun already owns the rights to Lighthouse Design's application suite. Since these were originally developed for NeXTstep/OpenStep, they should be relatively easy to migrate to Cocoa. I'd sure like to see an Improv/Quantrix like spreadsheet tool put a stake through the heart of Excel!
From the blog:
The problem has always been that OO.o makes assumptions about GUI development that are well-suited to X11 and Windows, and not well-suited to Aqua. The question is, can someone who's learning Mac development as he goes push changes back to OO.o to make it more suitable for Aqua and other GUI toolkits? Can he do it before Sun changes their mind and de-funds the Mac port? Sun has a habit of funding things for about six months and then getting cold feet.
Which reminds me: I should throw some money at Ed and Patrick for their continued work on NeoOffice, which uses Java as a GUI adapter (!) to get OO.o tolerable on the Mac
I use to have a dual G4 machine 5 or so years ago when OS 10 came out and it ran Open Office. I think the big problem is that it used the X interface instead of Aqua, so maybe that's what they're concerned about. But from a user perspective I had no problem using just the plain ol' X11R6 version. Think it was via Fink.
Having Improv back would be wonderful. The best spreadsheet I've ever used - using Improv made using Excel or other grid based spreadsheets painful.
But then too, there was also this oddball thing called (I think, its been some years) "Advance", I only had a couple weeks to play with a test copy. Very powerful, rather strange. I'd like to have that back to play with too.
Huh? Read the summary? This guy didn't even read the title!
being vague is almost as cool as doing that other thing...
It still pales in comparison to MS Office.
Yes, I am complimenting Microsoft -- I am sure I'll be flamed for it. But frankly, they make the best office suite, and since theirs is the standard look and feel (although the new Office is a departure), the other guys have to play catchup.
I would love to use OpenOffice, I just hate the look and feel and have always been more comfortable in Microsoft Office.
The price is always right if someone else is paying.
So I say, bring it on! I think that getting a good implementation of OOo running natively under Aqua is key in the cause of reducing reliance on Microsoft. People switching to Linux obviously are going to use OOo or some other open format, but still too many people switching to Mac are relying on Microsoft. It'll be curious to see whether they take Firefox's approach to have the interface be consistent across the board, or if they try and take advantage of OS X's toolkits and design guides to make it a true Mac application.
I'm not optimistic about an OO port to native Mac, regardless of who is on board with it. Why should I be, given the legendary code cruft of OO, the lousy relationship relationship dynamics between the Mac- and non-Mac developer leads on OO, the well-intentioned-but-ghastly-performance object lesson of NeoOffice?
OO is very decent office suite on Linux and Windows. So leave it there, where it is working acceptably. I think any effort to take that code base and reconcile it to an acceptable UI and functional level on the Mac will be the definition of a trip down the rabbit hole, taking years to realize and resulting in a UI compromise that annoys users on all platforms.
Time to cut bait on this, accept that it never will be workable on the Mac, and free its development team to focus on improving it in the Lin/Win world. Better to spend development time and effort developing a Mac-specific office suite that uses the various Open*** file formats as its native storage, while providing a real Cocoa-based UI experience that actually integrates into OS X the way Mac users expect an application to. Not that Sun will come within a mile of such an initiative, but it's a great opportunity for frustrated Mac developers looking to solve a real practical problem...
Err, that's rubbish. NeoOffice opens the default browser when there's an update. The update page happens to have a donation message on it, but the main thing is to inform you that an update is available!
Here is NeoOffice's official statement.
W
-------------------
This is my SIG. There are many like it, but this one is mine.
Disclaimer: I am a founder of the NeoOffice project.
Quote: and became an even worse idea when Apple deprecated the Java-Cocoa bridge
We never used the CocoaJava bridge at all. I guess you never bothered to read the source code. In fact, we use very little Java at all as is pointed out by the ohloh source code analysis of our open CVS. There's little Objective-C as we do most of the logic in C++ and call out to ObjC when required. There are some other stats there you may find intriguing as well like the estimated man-years and cost it will take to approximate our code.
Trust me, once any OS X port of OOo starts getting font handling and input methods correct, it'll slow down as well. This is true especially for Asian and other foreign languages. The bottleneck is in Apple's ATSUI and how it mismatches to the underlying OOo code. Has nothing to do with Java at all. Speed in a vaporware demo is one thing; carrying speed into a functional product is something different completely.
ed
Carbon is not justthe path of least resistance... it's the *only* option for cross-platform stuff unless Apple releases OpenStep again or endorses GNUstep... and that still won't help existing applications.
Safari is a wrapper around Webkit. Webkit is a port of KHTML, written in C++, and is the majority of the code in Safari: any Cocoa code is in the "shell" or in what are effectively Cocoa plug-ins. Camino is a similar wrapper, though somewhat simpler, around the Gecko HTML component from Mozilla/Firefox. This is the approach that I mentioned when I talked about using the original application as a support library.
The reason Finder sucks is not simply that it's Carbon, but that it's a mutant crossbreed of the NeXT file browser and the original Classic Finder. Apple really messed up there, the basic approaches to file management in NeXTstep and in Finder are vastly different, and the result of this blending of the two approaches has pleased nobody. Even rewriting it in Cocoa wouldn't help unless they abandoned all the original Finder behaviour (which would really piss off the old-school Mac fans) or abandoned the file-browser behaviour (which would piss off everyone else).
I really think they'd be better off starting fresh with the NeXT file browser, updating the NeXTstep code and making it pretty and Aquafied, and ripping all the Browser behaviour out of Finder completely and making it purely a "classic Finder" implementation.