Errr...umm....how about Keynote to replace Powerpoint?

Otherwise you have to wait for the installer to be finished.

Since building it requires fink (which I hate) and I am building far too many other things at the moment, I will wait.

I am glad to see it though.

I would prefer seeing OpenOffice being able to handle everything from the same build tree like almost everything else I build for OS X.

Maybe one day they will have things together enough to merge the trees.

I expect that they will have to do a lot more work for that to happen though.

In Ulrich Drepper's paper on writing shared libraries [redhat.com], there is a discussion of why it takes so long to start up. Debian lets you use prelink [redhat.com] to speed up the dynamic linking time. I dunno how much speedup you get.

From Drepper's paper:

With the knowledge of the hashing function and the details of the string lookup
let us look at a real-world example: OpenOffice.org. The package contains 144 separate DSOs. During startup about 20,000 relocations are performed. The number of string comparisons needed during the symbol resolution can be used as a fair value for the startup overhead. We compute and approximation of this value now.

The average chain length for unsuccessful lookup in all DSOs of the OpenOffice.org 1.0 release on IA-32 is 1.1931. This means for each symbol lookup the dynamic linker has to perform on average 72 x 1.1931 = 85.9032 string comparisons. For
20,000 symbols, the total is 1,718,064 string comparisons. The average length of an exported symbol defined in the DSOs of OpenOffice.org is 54.13. Even if we are assuming that only 20% of the string is searched before finding a mismatch (which is an optimistic guess since every symbol name is compared completely at least one to match itself) this would mean a total of more than 18.5 million characters have been loaded from memory and compared. No wonder the startup is so slow, especially since we ignored other costs.

i agree. fink is still on gnome 1.4.1, which is just...ridiculous, really. (unstable doesn't count, for a number of reasons)

Try Nisus Writer Express [nisus.com] out. It's simply the best word processor for OS X. Yes, it is a commercial product, but it's worth the $59.95.

I know I don't have to mention it, but Keynote is where it's at if you need to do a presentation. At least with these programs you can have part of an office suite.

I'm still looking for a decent spreadsheet program myself. So if anyone knows of a native OS X spreadsheet program that is at least on par with Nisus Writer Express or Keynote please enlighten us all.

OO.org is dead for me as well. It started when I downloaded StarOffice back when I was using Windows, can anyone tell me why the hell I needed two taskbars and two start menus? wtf. Now I know OO.org isn't like this anymore, but things still bother me about it. Like the file path in the toolbar, ugly, useless and tacky.

A new build of AbiWord popped last week. I thought it was pretty decent.

I don't know what system you're running that code on, but unless it's rather older than the earth i'm sitting on, it's likely to have a cache. Try the same thing with a random stride.


int main() {
char* bigarray = (char*) malloc(1<<24);
for(unsigned int i = 0; i < 18000000; i++){
int r = rand() & ((1<<24)-1);
char fetched = bigarray[
#ifdef BLOWCACHE
r
#else
0
#endif
];
r++; fetched++;
}
return 0;
}


(Compile with -O0 and check the assembly code to make sure the fetch isn't thrown away; it isn't on my machine.) Without BLOWCACHE defined:


real 0m2.302s
user 0m1.840s
sys 0m0.020s


And with:


real 0m8.844s
user 0m7.200s
sys 0m0.150s


Bring the size up from 16MB to 256MB and on my machine (with 512MB of ram) it takes about three minutes before I get bored and give up. Get it now? Your test isn't exactly applicable.

Having ported other (admittedly small) apps from Linux to OSX, I'd have to say that it's highly unlikely that any work that is done for the OSX/X11 is "wasted", as most of the porting is likely to be from the library/kernel differences, not from moving from one XFree86 install to another.

The waiting-on-2.0 is because 2.0 will have an abstraction layer above the UI toolkit, which will also allow native Gtk/Qt builds.

If nothing else, this can help them gather interest (and thus developers) *now* instead of in a year or more, when the native version might be ready. Except it won't without help...

According to the OO website, they will not be doing an Aqua port until 2.0 because the graphics code is to be completely rewritten then; any work they did on it now would be thrown away in just over a year.

I had been using OpenOffice on my Mac to remain compatible with the OO.o docs I had created on my Linux systems but as you say it was ghastly. Recently I tried out NeoOffice/J (http://www.neooffice.org) which removes the need for X11 and looks better as it is at least somewhat integrated with the desktop. Still not aqua but it is a definite improvement. It is based on 1.0 which means it isn't quite as nice as 1.1, maybe it will be updated with this new release of OO.o. They are also working on testing approaches to aquafication but are rightly waiting until 2.0 of OO.o comes out as it is going to be more portable.

In then end I had to stump up money for MS Office X which frankly I hate. It is unreliable (crashed 6 times while trying to edit a powerpoint file created on Office XP) and doesn't produce files that are completely readable by Office on a PC so it is barely and improvement over OpenOffice. However, it does start pretty quick and people don't seem to complain about the necessary tweaks to fix font problems and layout as that is expected when moving docs from one version of MS Office to another. Of course, when the same thing happens with conversions between OO.o and MS Office it is the fault of OO.o and I should use MS Office even though OO.o rarely produces more severe problems than my copy of Office X....... sigh.

my ibook doesnt have enough resources to run it with X11. I'll just have to stick with the lighter faster Office X or the native Koffice port when it gets better.

I think you're laying the blame in the wrong place here. Until the main source team has completed certain parts of the 2.0 code, the 2-man porting team can't even really get started on the porting effort (and we're not going to see a full attempt at getting OO.org to OS X with anything but the 2.0 source).

So where should Apple throw their developers? Put them to work on the main source? THEN pull them off and put them on the porting effort? No.

The job is a big one, and the payoff just wouldn't be there at this moment in time. As soon as the 2.0 source is more complete and the porting work can begin, maybe then we will see Apple commitment (in the OS X port ONLY).

It's not Apple's fault, it's just that complex software takes time, and OO.org is pretty complex. Sure, the porting team could attempt to move OO.org 1.1.1 to native Aqua, but all their work would be broken with regards to 2.0, as the source is changing significantly in this transition (a lot of it to do with abstracting interfaces so that this kind of problem is surmountable and we can get an Aqua version).

But sadly, we're just going to have to wait - it's a big job, and Apple have much more pressing things to put their developers on than a two year project involving fixing up the main OO.o source, then moving to another 6 month - 1 year project to port it.

At the moment, Apple gains a lot from being able to claim Microsoft Office support, especially with the new Office 2004 coming soon. How much business sense does it make to be seen to be throwing your resources all over the shop into a competing office suite when despite that effort, the suite isn't going to be available for over two years? Not a lot! The way Apple should/is playing this is to support MS Office on the platform as it's really needed, and only attempt to publicly move momentum to something like OO.o when the transition can be swift, and OO.o is near mature for the platform.

Look at what happened when Apple supported the open source KHTML engine for Safari, as soon as Microsoft were snubbed they removed IE support. Luckily Safari was (juuuust about) ready to fill the gap left by MS. Now look at OO.o - it is NOT ready to fill the gap left by MS (as evidenced by all the posts here) how bright would it be to give MS any excuse/reason to withdraw support for Office on OS X before a replacement is ready to be announced?

As for KDE rivaling OS X, well each to his own I guess. You say that there is little that will be in Panther that won't be in KDE in a year - well I think more accurately would be 2-3 years... and then you are forgetting that Apple updates their OS too, and in that timeframe OS X would be moving forward also.

In terms of "Linux & Co breathing down [OS X's] neck...", well I would love to see a Linux distro give me what OS X gives me (then I wouldn't have to pay for it!) but I simply don't think you're right. Look at how things have moved ahead in the last three years (since OS X 10.0). Sure, KDE and Gnome have made nice enhancements, significant ones, much needed ones too. But when you compare where KDE/Gnome and OS X (or Aqua I guess) was three years ago, and where they both are today - the paths are NOT converging, OS X is moving further and further ahead at a fantastically TREMENDOUS pace... sure KDE and Gnome WILL implement the same features, but these features will by their nature be copy-cat features, and OS X at the moment is simply moving faster adding new features than KDE/Gnome can copy the old ones.

Instead of pissing in the wind with X on Mac, all of the effort should be for the native aqua version. The X version looks horrible and performs horrible.

But it's available now. If they'd insisted on doing a native Aqua port instead of building and maintainging the X11 version first, OpenOffice for OSX would still be vaporware... vaporware that a lot of people would be sitting on the sidelines questioning whether it was ever going to happen. This way we know that OOo is going get ported to OS X, because it already has. That builds confidence, establishing that OOo is a real cross-platform app, not just a Linux app that's been successfully ported to one other OS.

That's particularly important to me, because it means I can finally run the same wp and work on the book I'm writing (on a USB keydrive) on my iBook out on the front porch, during my lunch break on my Windows machine at work, or in the wee hours on my main desktop running Linux. That's so much more convenient than some kludge importing/exporting files with AppleWorks, and worth putting up with the painfully long launch time of OOo 1.0 on a G3/500 (I leave it running and put the iBook to sleep between uses) and the Win/Lin-looking UI.

It's a damn good thing AppleWorks is coming with it....

Depending on what functions your cousin needs, there are other non-MS apps available for OS X (Nisus Writer, Mariner Write/Calc, FileMaker).

Asking one of these people to "put in X, and then compile OpenOffice".

Compile? 1) Download X11 from Apple.com and run the install package. 2) Download the latest OOo*.dmg file (one for 1.1.1 should be along soon) and run the install package. It may not be fully noob-compatible, but it's not as difficult as you make it out to be.

The people at NeoOffice.org [neooffice.org] are working on two parallel OOo ports. The first, NeoOffice, attempts to port OOo to Aqua. It seems to have stagnated, but the very promising NeoOffice/J [planamesa.com] is rapidly approaching 1.0!

NeoOffice/J replaces the dependency on X with a dependency on Java, which is treated as a native toolkit in OSX. NeoOffice/J may not look like an Aqua app yet, but it does integrate nicely with the AA fonts and can use OSX's copy and paste. It takes a good 30 seconds to launch on my G3 iBook 700/640MB RAM but once it's up and running it is quite fast. I recently removed the OOo X11 port from my machine, as NeoOffice/J works more consistently for me.

NeoOffice/J is based on OOo 1.0 but it's still much better than nothing, not to mention much better than the X11 port. It's very easily installed with a DMG file and the standard Apple installer, once installed it behaves like any other OSX app, setting up the MIME types properly, etc.

I've installed 0.82 in the Mac lab here at work, as we didn't purchase MSO with the machines and students were trying to open PPT lectures. Anyway, I'd take NeoOffice/J over AppleWorks any day of the week. I even prefer it to MS Office on OSX. (Sorry, it may look Aqua-ish, but it's an odd duck too.)

----------------------

From the NeoOffice/J site:

No X11 software required

NeoOffice/J uses the JavaTM technology that is built into Mac OS X. By using Java, there is no need to download and install the X11 software that OpenOffice.org requires.

Integrated with Finder and Mail

The Mac OS X Finder will automatically launch NeoOffice/J and open OpenOffice.org and MicrosoftTM Office documents that you double-click on. Also the Mac OS X Mail application will open OpenOffice.org and Microsoft Office attachments in NeoOffice/J.

Uses Mac OS X fonts

Unlike OpenOffice.org, NeoOffice/J uses the same fonts that all of your other Mac OS X applications use. This means that NeoOffice/J will handle reading and writing of Western European characters (e.g. characters with accents, umlauts, circumflexes, cedillas, etc.) and some fonts will even handle Japanese, Chinese, and Korean ideographs. Also, NeoOffice/J is able to use any fonts that you install in your Library/Fonts subfolder or the /Library/Fonts folder.

Handles international keyboards

Unlike OpenOffice.org, NeoOffice/J will use an keyboard layout that you use. I routinely switch to a Spanish keyboard without a problem. Also, if you switch your keyboard layout while NeoOffice/J is running, NeoOffice/J will automatically switch as well.

Native printing support

NeoOffice/J supports printing using Mac OS X's native printing functionality. Like other Mac OS X applications, you can use NeoOffice/J to print, preview, or save a document to a PDF file.

Native copy and paste support

NeoOffice/J supports copying and pasting using Mac OS X's native clipboard so you can copy and paste text and images between NeoOffice/J and other Mac OS X applications.

Um, this [redlers.com] looks like a screenshots page to me.

So I went through the suggested Word processors, mostly I had tested the apps before already.... Here are the results:

(totally unscientific test, mostly based on personal preferences)

Testing on my wifes iBook G3 700, everything that needs three times longer than MS Word, fails (Thinkfree office, Nisus)

MS takes ~8sec launch and open a file with 21 pages, several images, some text is highligted. Header, footer and page counter. The file has been created with v.X and then tortured by MS Office 2000 on windows.

Three formats saved in Word v.X: .doc 337kb (the original) .doc Word 95 compatible mode 272kb .rtf 2.2mb

NeoOffice/J is disqualified. It's over 100MB, based on OO.org and using Java - no chance it can start and load a file in less than 25sec.

koffice qt/mac is pre-alpha and last time I checked it was a load of files to dl and it too quite a while to load on a Powerbook...

TextEdit: ~4 sec.
Pros: opens all pages in the DOCs and the RTF, the result is acceptable.
Cons: No headers/footers or images. No highlight in rtf and 95 compatibility mode. Original v.X save does have highlight. Core functionality.

AbiWord v2.1.1 ~12sec
Cons: RTF fails totally to open, resulting in a crash. both doc files end after the 3rd page for no reason. The toolbar is OSX unlike fixed under the menu bar... destroys the overall good look. The file opening process has no indicator and looks broken ugly until suddenly the file opens.

Pros: The opened 3 pages look good, nearly like they are supposed to look like. The icons in the toolbar look simple nice the toolbar is usable.

Nisus Writer Express: ~26sec (rtf:14sec)
cons: converts docs to rtf. no highlighting, some images are missing slightly too simplistic toolbar. rtf looks more broken than the doc>rtf conversion, all images loaded however

pros: result looks good except for the mentioned things, good use of the OS.X drawer. big plus for functional thesaurus. I would use it if it had better MS rtf/doc support.

Mellel ~6sec
uses that safari metal interface - basically TextEdit with usable interface around it.
pro: cute floating functions thingie
cons: does not open .doc (TextEdit does!), Does handle rtf same as TextEdit. (no images, etc..)

Papyrus ~16sec (plus bugging me to replace missing fonts? whatever.)
cons: no images, Ugly toolbar. Confusing icons. Need to use menus a lot. did not open both .docs
pros: best import of header/footer and pagecouter so far. Slightly better than TextEdit.

Thinkfree ~36sec
cons: takes too long to startup and load the file it's actually unacceptable to wait this long.
pros: loaded text looked acceptable... RTF: TextEdit quality with some images. DOC: good text import with some images and some were cut/misplaced. Windows Office like toolbar. not the prettiest interface

Vi: ~3sec
pros: opened all files.

Conclusion:
Vi loaded the fastest and opened all files. Nisus performed ok, took it's time to load docs, but I would like to highlight the interface. I really liked how they use the drawer, the thesaurus functionality was nice and I have not seen it before in any other app. It would be my personal favorite if it opened files like AbiWord did to the first three pages, the toobar might have some more icons/functions to add too... My second choice would be AbiWord (if you ignore the rtf crash), I hope future updates can fixed that cut document bug and somebody can make it more native. eg take the interface from Nisus ;)

Everything else was not so ok... partially TextEdit was better.

Overall, I am still waiting. My bets would go on the AbiWord project.

Let's face it - MS compatibility is important. I think I will keep Nisus on the disk to play with until it expires and check out future releases of AbiWord.