Slashdot Mirror
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."
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
Combination - fun iPhone puzzling
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.
Ripping an new rectum in the fabric of spacetime.
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.
You are not alone. This is not normal. None of this is normal.
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.
Sig erased via substitution of an identical one.
"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.
--
make install -not war
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.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
I don't know what kind of crack I was on, but I suspect it was decaf.