OpenOffice.org for Mac OS X Alpha Released!

An anonymous reader writes "Nearly 6 years after announcing a Mac port, OpenOffice.org has released the first release of OpenOffice.org for Mac OS X that can finally run without X11!! An alpha is available for download today, but a lot of help is still needed to make OpenOffice.org available for Mac OS X. The site is very blunt: 'WARNING: THIS SOFTWARE MAY CRASH AND MAY DESTROY YOUR DATA DO NOT USE THIS SOFTWARE FOR REAL WORK IN A PRODUCTION ENVIRONMENT. This is an alpha test version so that developers and users can find out what works and not, and make comments on how to improve it.' Currently missing functionality includes printing, pdf export, copy/pasting, and multiple monitors. That said, if you're interested in participating you can visit the Mac team to figure out how you can help today."

Comments

REALLY READ THAT WARNING MESSAGE

[Chris_Jefferson]

While this is cool, make sure you really read that warning message. This is real alpha. You won't be able to print. You won't be able to cut+paste reliably. As this alpha has been approaching, I had a crash while saving, leaving me with a half-corrupted useless copy of my document.

So have a look, and help submit bug reports, but please don't try using this is your normal editor, or get annoyed it isn't in a full usable state yet, that's why it is called alpha :)

Re:REALLY READ THAT WARNING MESSAGE

[jalefkowit]

You won't be able to print. You won't be able to cut+paste reliably.

Finally! An office suite on OS X that works just like OpenOffice does on Linux! ;-)

Neooffice - differences?

[cyman777]

OK, so I will start the obvious thread:

What are the differences to Neooffice?
Are they working together?

Besides the slow startup I feel Neooffice already has taken that niche, hasn't it?

Re:Neooffice - differences?

[squiggleslash]

This is a genuine native port, NeoOffice uses a Java intermediate layer to present the UI to Mac OS X.

As I understand it, they're not working with the NeoOffice people, there's always been a little friction between the groups.

In time, this project is likely to overtake NeoOffice, simply because changes to OpenOffice.org will always be faster than those in NeoOffice, which is in a continual state of catch-up.

Re:Neooffice - differences?

[squiggleslash]

Not trying to troll here, and maybe you don't even ascribe to the mindset you imply with the above line, but how can you "overtake" a project that's "in a continual state of catch-up"?

When you start off behind in some areas, but not in others, and in the "others" you can only ever be ahead of the rest. OpenOffice.org's Mac port is at an early stage at the moment, so it implements all of the latest version of OpenOffice.org (by definition) but not all of the Mac native subsystem. NeoOffice includes a complete Mac native subsystem, but not all of the features of the latest version of OpenOffice.org. As time goes by, because making OpenOffice.org native is a discrete, completable, task, OpenOffice.org will catch up with the part of NeoOffice it currently lags behind, but NeoOffice cannot catch up with OpenOffice.org (unless OpenOffice.org ceases to update.)

Does that make sense to you?

Re:Neooffice - differences?

[AttilaSz]

You're wrong. "Carbon" is the collective name for all native Mac OS X APIs, see http://developer.apple.com/carbon/. Quartz, Core Data, Code Audio, etc. are all parts of the umbrella technology set called "Carbon". "Cocoa" OTOH is a handy Objective-C object-oriented abstraction layer atop of that, which is supposed to make development of applications easier. In Windows terms, Cocoa is to Carbon as MFC was to Win32 - an OO encapsulation of the API with convenience goodies. But you can program directly for Carbon if you wish, in the end you have the same capabilities available to your code, it just usually takes less time and lines of code to use Cocoa than Carbon directly. Therefore, it is a perfect solution for you app that you build from scratch. If you're however porting an existing app and it's not trivial to sneak in Objective-C into it, you'd probably go the Carbon route. Nothing to frown upon :-) The misunderstanding comes from Apple's advertized "carbonization" of OS 9 apps ("you need to use Carbon to have your apps run on Mac OS X"). What it really meant was - replace QuickDraw calls with Quartz calls in your source code etc. Carbon is *THE* Mac OS X API, not some transitional support layer for OS 9 migration.

Re:Neooffice - differences?

[spud603]

Adobe uses Carbon for its CS3 suite. Microsoft uses Carbon for Office. Game developers (EA) use Carbon
And apple uses Carbon for Finder, a fact that annoys the hell out of me on a daily basis.
Two things off the top of my head that are implemented in Cocoa apps but not Carbon apps: emacs-style text navigation (ctrl-F,ctrl-B, etc) and on-the-fly word definitions (ctrl-cmd-D while cursor is over a word). There are other differences, too, but I only notice them when they don't work in Finder or in Camino (or Photoshop!).
That said, it's a hell of a lot more integrated than Java!

Re:Neooffice - differences?

[larkost]

You have this almost right...

Many of the sub-systems, especially in things like drawing and sound, often have the more robust API written in Carbon, and then some of the Cocoa API's call those APIs while running. But generalizing like you do that Cocoa is built on Carbon is a mistake, there are many sections of Cocoa that have no Carbon at all underneath them.

A better concept of the major MacOS X API's are that at the root of things you have a layer called CoreFoundation that is written in C. This sits next to the APIs taken from FreeBSD (and the latter dangles down into the Kernel space as well). The primitives from Carbon are often found here, but that is not to say that these belong to Carbon. The primitives found in Cocoa are all built around these, and are often interchangeable with them in some regards.

On top of this you have the "Foundation" layer. This one is mostly written in C or a sub-set of C++ (basically the stuff that does not conflict with Obj-C). Many of the "core" services at the heart of the OS are built here, and at the top of this things start to blur with the bottom of the Carbon layer. Services such as Quartz (but not QuickDraw... which sort-of sits on top of Quartz... but that is messy) sit on this layer.

On top of this layer comes Carbon and Cocoa proper. There is quite a bit of messiness with the two of them calling back and forth, and there are some areas (like Quicktime) that have been very slow to get full implementations in "pure" Cocoa. And a lot more that have had real speed penalties for calling from Cocoa.

Carbon's roots go a little deeper (but less so every new version of MacOS X), but Cocoa and Carbon are philosophically on the same level.

Re:Neooffice - differences?

[Creepy]

They originally disagreed over licensing, now they claim it's much more efficient to just write mac code and not have to coordinate with other platforms - basically, they're saying its easier for them to maintain a fork than it is to coordinate with OOo. The bottom line, however, is NeoOffice code is all GPL, so there is no way for them to legally contribute any of their code to OOo without violating the GPL (unless the original writer submitted it). I don't think OOo is going to move to the GPL, so you've got an impasse.

the "6 year wait" is partly because OOo 1.x was incompatible with MacOS X because of the way symbol bindings were handled (I think it was basically a hack, anyway, exploiting a "feature" in most UNIX-based OSes), so the port really couldn't start until 2.0 (which was heavily rewritten). I was involved in another project when 2.0 came out (I believe STLport, which I think I actually got involved with due to OOo, but X.3 had all the STL features I needed, so I moved on), so I really didn't follow the split that started NeoOffice.

Re:Neooffice - differences?

[diamondsw]

Why is there no moderation "-1 Flat Out Wrong" ?

From the horse's mouth.

Carbon is NOT a fundamental API of Mac OS X. It sits side-by-side with Cocoa, and while it DID start out life as a transitional API from classic Mac OS, it is a peer API of Cocoa. In particular, if you can't deal with Objective-C, you'll likely be using Carbon as it's procedural and accessible from C/C++. Both Carbon and Cocoa are built atop the various "Core" API's. Remember that Mac OS X is a very direct descendent of NeXT, and as late as Rhapsody DR2, there was no such thing as Carbon.

Neo Office

[Anonymous Coward]

http://www.neooffice.org/

A port of OpenOffice to Mac OS X that uses Java as a compatibility layer.

It _is_ production ready (I use it every day).
Why the OpenOffice people are hostile to this project is something I've stopped
wondering about... today's announcement of the "first" port of OOO to Mac not
using X11 just shows how badly a project hurts itself when it refuses to work
with others

Re:Neo Office

[swillden]

Licensing. NeoOffice code can not be reused in OpenOffice.org due to their relicensing to GPL from the original LGPL.

This is incorrect. The problem isn't GPL vs LGPL, the problem is that Sun requires the copyright for all significant contributions to OpenOffice.org to be assigned to Sun, so they can sell StarOffice as proprietary code. The NeoOffice developers don't want their code sold as proprietary, and don't want to assign their copyrights to Sun.

Re:Neo Office

[808140]

That seems distinctly unfair. Don't the BSD and LGPL people always say that they don't care if people "take their code proprietary" as it were, and that "the code is still there even if someone else improves it and doesn't share back?" Why, just yesterday there were hundreds of comments to that effect on the GPL2 vs GPL3 story!

It's funny though, because it seems that for all their rhetoric about how using BSD and similarly "non-viral" free software licenses is somehow "more free", BSD/LGPL people generally aren't happy at all when people relicense their code. BSD people hate it when their code gets relicensed, ironically especially when that license is the GPL (for some reason, having their code co-opted by Microsoft or Sun bothers them less -- how does that work?) The LGPL is just like BSD, except that it is exclusively GPL-compatible by design. If it bothers you that someone is releasing mods to your LGPL-licensed program under the GPL, why on earth are you even using the LGPL?

Host and parasite -- god, I love it. Talk about double-speak! It reminds me of this great exchange between an interviewer and Theo de Raadt (whom I have the utmost respect for, as it happens, but this attitude is typical of BSD types):

NF: Lots of hardware vendors use OpenSSH. Have you got anything back from them?

TdR: If I add up everything we have ever gotten in exchange for our efforts with OpenSSH, it might amount to $1,000. This all came from individuals. For our work on OpenSSH, companies using OpenSSH have never given us a cent. What about companies that incorporate OpenSSH directly into their products, saving themselves millions of dollars? Companies such as Cisco, Sun, SGI, HP, IBM, Siemens, a raft of medium-sized firewall companies -- we have not received a cent. Or from Linux vendors? Not a cent.

Of course we did not set out to create OpenSSH for the money -- we purposely made it completely free so that the "telnet infrastructure" of the 1980s would die. But it sure is sad that none of these companies return even a fraction of value in kind.

If you want to judge any entity particularly harshly, judge Sun. Yearly they hold interoperability events, for NFS and other protocols, and they include SSH implementation tests as well. Twice we asked them to cover the travel and accommodation costs for a developer to come to their event, and they refused. Considering that their SunSSH is directly based on our code, that is just flat out insulting. Shame on you Sun, shame, shame, shame.

I will say it here -- if an OpenSSH hole is found that applies to SunSSH, Sun will not be informed. Or maybe that has happened already.

That's from this interview with Theo at NewsForge if you want to read the whole thing. But basically, there's this tremendously hypocritical attitude among the most ardent supporters of licenses that are presumably "freer than the GPL". I see nothing wrong with the classic BSD/PD stance: "We don't care what you do with it, no matter what we still have the original copy". I think that's a noble way to look at things. It just seems that in practice, that's almost never how it is. Someone turns around and creates something useful from your code and relicenses it in a way that prevents you from benefiting, and suddenly they're evil, even though that's supposedly a right that you expressly wanted to guarantee to them in the first place!

Released?

[reality-bytes]

You know, "released" when applied to software commonly means software which is considered (rightly or wrongly) to be 'production' material.

This however is apparently an 'alpha' which is commonly an early development version, not fit for general consumption and the type of thing you might get from CVS or a daily tarball.

Some developers use the term 'alpha release' as they assume others will know it's just a packaged up development snapshot, then some muppet takes it and runs to press with it.

Warning!

[Rob T Firefly]

'WARNING: This software may crash and may destroy your data Do not use this software for real work in a production environment.

Do not taunt Happy Fun Software.

Re:Warning!

[CockroachMan]

'WARNING: This software may crash and may destroy your data Do not use this software for real work in a production environment. Windows should have one of those in the box..

Re:Used it on MacOSX - switching to google docs

[Anonymous Coward]

not to mention having every single thing you write indexed for public consumption and advertising goodness...

google...you seem to apologizing to you girlfriend.
would you like to

1. order flowers
2. seek counseling
3. look up a local escort service

Thanks to neooffice...

[MMC Monster]

Just wanted to give a thanks to the folks behind neooffice (http://www.neooffice.org/) before all the bashing starts...

Not Alpha

[Doc Ruby]

"Alpha" testing is testing by people who participated in the design and/or implementation. Any testing by people not in those teams is, by definition, "Beta" testing.

Alpha/Beta/Release is not a measure of quality or maturity. It just tells who is testing, and their relationship to the software.

Re:Not Alpha

[shawnce]

Actually in many schools of thought those levels have everything to do with quality and completeness.

Alpha = feature incomplete software with bugs, Beta = feature complete software with bugs, Release = feature complete software with ideally very few bugs.

Re:Good news

[LKM]

The problem is that Apple X11 implementation is crap (...) it disqualifies X11 apps on OSX to rest of the world (apart from geeks).

And this is precisely what Apple wants. X11 on the Mac is for Geeks, not for "regular" users. The existing issues with X11 are intentional.

Let me explain what I meant

[LKM]

> And this is precisely what Apple wants. X11 on the Mac is for Geeks, not for "regular" users. Yeah so maybe just throw out some source code of X11 that barely compiles and you need to fix it yourself. No binary release - then it would be even geekier. :)

Not sure what you're trying to say here.

> The existing issues with X11 are intentional. Yeah. :) That is what I love Mac fanatics - if something is broken in OSX it must be intentional. LoL.

Labelling people "mac fanatics" because you don't understand their reasoning is pretty cheap. In your defense, I admit that I was unclear in my original post. Let me explain what I meant.

Apple depends on Mac OS X having applications which do not exist on other operating systems. It's a competitive advantage. Remember NeXT? They had a nice cross-platform development library which allowed NeXT apps to run on Windows. Initially, Apple planned to keep this in OS X. It was called "yellow box" ("blue box" was for old Mac apps).

Interestingly, the idea didn't survive. Eventually, Cocoa became Mac only. Why? Because Apple wants Mac-only applications.

Another example is Java. Making Java apps look good on a Mac is hard. Apple wants to discourage Mac developers from using Java to create cross-platform apps. They would rather keep apps Mac only.

And this brings us to X11. X11 is awesome if you want to run all kinds of apps on the Mac, but these apps don't behave like Mac apps. Why? Because if they did, it would be trivial to write Mac apps using X11 and then port them to other operating systems. Apple would rather keep these apps on the Mac, thus they are discouraging the use of X11 for Mac apps.

Do you now understand the reasoning, or are you still LOLing at me?