Slashdot Mirror

What's wrong with "messing with X11"? Is there some other windowing system you'd rather get your customers to use on Linux?

If you meant on Windows or Mac, there's no reason to, if NeoOffice/J is what it claims to be.
http://www.neooffice.org/

NeoOffice is a Java port of OpenOffice.org that runs on Mac OS X without the need for X11.

This means that it uses Mac OS X's fonts and font rendering, which is a huge improvement over X11. It has Mac OS X menus, and will get Mac OS X dialog boxes "real soon now".

It's excellent, and it's been developed by two, count them two, programmers for the last couple of years.

http://neooffice.org/

They are separate from OpenOffice.org and they've done what nobody at OpenOffice.org was willing to do.

I use NeoOffice every day (word processing and spreadsheet). I made a donation to them last week.

Nice post - informative.

Just to mention that Neo Office http://www.neooffice.org/ was born due to no native version available under OS X. Its only available in a 1.x source tree due to the massive undertaking required to get it work.

I wish Sun would do a better job and make it run natively under OS X, get rid of those static assigned libraries (.dll / .so) would be a nice start.

Also some beautiful / appealing templates in Oo such as those which are available in Apple's Pages would be fabulous.

I run Office under OS X because I can't afford any threat of loosing format, my documents heavily rely on templating and styles for consistancy across documents with other collegues.

But I put everyone else on Oo, its a great platform for those who don't require so reliance on formatting.

As OpenOffice 1.1.x (and thus NeoOffice too) handles fonts internally, it has to load native fonts during startup. This can take a long time if you have lot of fonts. OO.o/X11 should start faster, but it may has other problems. See this thread for more information.

qz

NeoOffice/J.

May be to use NeoOffice instead?

How to submit code to OpenOffice.org

We ask that all code submitted to OpenOffice.org be submitted via Issue Tracker . In your submission please list "Issue Type" as PATCH. Your code will be sent to the committer for the appropriate project.

     

1. Submit a filled-out copy of the Joint Copyright Assignment form (JCA); we have a PDF version you may print out. We explain our reasons for requiring the JCA in the Licensing FAQ. The FAQ further explain the use and advantages of using this license.

You can however take Openoffice.org code and submit it to Kword or Abiword,

This is not FUD, it is a reality check that Openoffice.org does not have access to as much GPL code as projects that do not require Copyright assignment.
NeoOffice can add the the grammer checker that abiword uses because they do not require copyright assignment.

Sun and the Free Software Foundation like demanding copyright assignment, but they also get limited contributions from the community and seem to spend time complaining about it instead of realizing that many people don't like giving their work away for nothing. Kind of ironic since both organizations release software under the GPL.

http://www.neooffice.org/

"Our primary development effort is NeoOffice/J. NeoOffice/J uses a combination of Carbon and Java to make a truly native open source office suite."

No, it's not written in JavaScript (and I know that Java and JavaScript are totally separate) but NeoOffice/J is almost as foolish a replacement for Microsoft Office as JavaScriptOffice would be. NeoOffice is huge, sluggish, ugly, and is completely non-interoperable with any other Mac OS X application.

Well, I don't know about Apple, but I do know there's a Mac office suite ported from OpenOffice.org, so it should support the OpenDocument format. It's called NeoOffice/J and it can be found here.

Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.

Yes, there are some folks rethinking the standard interfaces...such as Apple (with Keynote and Pages) and even Microsoft with Office 12 and earlier some of the UI design of Office:mac. On some platforms, it would even be possible to play around with alternative OOo interfaces by using OfficeBean (although I don't know of any off of the top of my head).

For office suites, however, I think the general interface paradigms are so commonplace now that any radical departure will be greeting by a nice resounding "WTF is this" from users. Case in point: OpenDoc. It was, in my opinion, a valiant attempt at shifting the focus for productivity suites off of individual applications and onto a free-form content-centric view. The idea never caught on with users, and ones I always saw trying to use it were just confused by the idea and were still asking questions like "what do I open to create a spreadsheet?".

Not to mention I can't get that stupid "I just did the Excel..." lady from the Video Professor commercial out of my head. With millions of users like that, I doubt things will really be able to change that much :)

ed

Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.

Ever write code that just stores a pointer in a long and assume void * is the same size? Ever written Win32/Mac code where you dump a pointer in a window reference constant and then just cast it out? This happens quite a bit in the OpenOffice.org code. Of course, since such assignments require casting, they're still valid even if the size of void * is no longer the sizeof long. gcc4 may spit out a warning at you, but it'll still be valid C.

I could go off on how a word processor/presentation program really should have no underlying need to address more than 2GB of memory, but I'll leave that for another time...I almost can fathom spreadsheets, but really the unsigned int row index will bite you in the ass *waaay* before a 2GB per process memory limit :)

ed

Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.

As someone who's wrangled with the OOo build system since 2001, I have to respectfully disagree. While it is good that it supports so many different operating systems, the build system is also one of the major Achilles heels of OOo. Some examples:

• It builds its own build tools as part of its bootstrapping process. This makes it near impossible to cross-compile without completely retooling the build system (a pain for doing any type of single-machine PPC & x86 OS X builds).
• It has its own "make" equivalent that encodes module dependencies and language localizations in a custom format. To add appropriate dependencies you need to learn yet another makefile system. Don't mention trying to figure out the module build order without actually running a compile. Try it sometime if you want to lose your mind.
• It uses quite a few preprocessing tools for custom file formats for processing including slots files, IDL files that generate more headers, resource compilers, and more. Custom toolchains make figuring out what generated what file even more fun to discover.
• Some of the build tools have dependencies on versions of Java that do not exist on all the platforms on which the application might be able to run, preventing it from even compiling on those platforms.

The end result of all of this is that the entire 8 million line plus project is quite dependent on its build system in order to successfully compile. The system is so intricate that most all of the attempts to move it to a different system, such as XCode, have failed. This is a bummer. From a Mac perspective, it sucks ass to be forced to use command line tools for such a huge project. You lose access to such useful tools as the symbolic browser information (e.g. "Jump to Definition" for a symbol in an editor file) and within-project searches. Not to mention you don't gain access to other nice things in the environment like distributed compiles. Probably the worst side effect, however, is that most Mac developers aren't command-line junkies (unless they were MPW freaks like me). They've been raised on CodeWarrior and other great IDEs. It's a real turn-off to have to learn an arcane command line build system that is used for only one program and will probably not give you any useful skills for any other applications on the Mac platform. Forget about being able to examine the interface in InterfaceBuilder or ResEdit, too.

The whole complexity of learning the build system and all of the custom formats involved has been a real turn-off for many a Mac developer who just take a look at the build instructions and vomit. The lack of standard dev tools has definitely hindered my productivity, and I'm sure I'm not alone. A fantastic build system is one that doesn't get in a developer's way and on Macs at least, that's most definitely not the case.

ed

Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.

While licensing is part of the spats that have caused these forks in the past (note: RedHat has their own separate "fork"), it's not the only problem. It's the mentality of Sun (a.k.a "OpenOffice.org") developers as a whole. The patch submission process doesn't allow for innovation. Rather, it's a tedious sequence of submitting and resubmitting patches. In general, patches that add functionality for a single platform only are rejected...everything must target the lowest common denominator. Ximan's alpha patches weren't incorporated quickly enough to allow their icon set to work with 1.0.3, so they shipped using a different code line.

Simply changing licenses doesn't address the fact that if your code patches aren't what Sun wants, they just won't accept them. OOo development needs to move to a neutral body before real progress can happen.

It doesn't help that Sun, RedHat, and Novell have a secret development board that decides the development direction from OOo without any input from the community. (this is not random accusation...it was revealed to me by someone on the inside). Open source doesn't necessarily help the little guy.

ed

Disclaimer: I am a developer of the Mac OS X OpenOffice.org port as well as a founder of the NeoOffice project.

If anyone is affected by this, it will most drastically affect IBM. If you look at the original list of Sun Copyright Assignment signers, you'll notice that IBM is listed as one of the original signers. Curiously, this page is no longer accessible (the wayback machine lists it as blocked by robots.txt) and there are few IBM-OpenOffice.org references left. Has IBM made any source code contributions to the OpenOffice.org product? No. Why should they...

They develop IBM/Lotus Workplace. Workplace incorporates OpenOffice.org code directly and provides their Word/Excel style integration with the old Notes environment. Doubtless they have probably made enhancements to the code to support collaboration. Since SISSL allows for binary only distribution, however, IBM never had a need to join the OpenOffice.org project to develop Workplace. They could happily have their own team of engineers working on it and had no obligation to share that work with others under SISSL.

So is this a good thing? Who knows. IBM very well may just stick with the last version of source released under SISSL for Workplace. OOo 1.x/2.x is "good enough", so unless future LGPL only versions have some type of major advantage, there's no need for IBM to contribute back their Workplace enhancements.

This is really ironic, though, since LGPL was actually thrown into the original OOo license as an afterthought (I think by Joerg, but may be mistaken). The afterthought has won out!!

For me personally, this is a good thing since it legitimizes GPL-only forks like NeoOffice and hopefully can help them stop accusing us of stealing OpenOffice.org and engaging in illegal activities when all we do is exercise our rights under the LGPL license.

ed

Disclaimer: I am a developer of the Mac OS X OpenOffice.org port as well as a founder of the NeoOffice project.

If anyone is affected by this, it will most drastically affect IBM. If you look at the original list of Sun Copyright Assignment signers, you'll notice that IBM is listed as one of the original signers. Curiously, this page is no longer accessible (the wayback machine lists it as blocked by robots.txt) and there are few IBM-OpenOffice.org references left. Has IBM made any source code contributions to the OpenOffice.org product? No. Why should they...

They develop IBM/Lotus Workplace. Workplace incorporates OpenOffice.org code directly and provides their Word/Excel style integration with the old Notes environment. Doubtless they have probably made enhancements to the code to support collaboration. Since SISSL allows for binary only distribution, however, IBM never had a need to join the OpenOffice.org project to develop Workplace. They could happily have their own team of engineers working on it and had no obligation to share that work with others under SISSL.

So is this a good thing? Who knows. IBM very well may just stick with the last version of source released under SISSL for Workplace. OOo 1.x/2.x is "good enough", so unless future LGPL only versions have some type of major advantage, there's no need for IBM to contribute back their Workplace enhancements.

This is really ironic, though, since LGPL was actually thrown into the original OOo license as an afterthought (I think by Joerg, but may be mistaken). The afterthought has won out!!

For me personally, this is a good thing since it legitimizes GPL-only forks like NeoOffice and hopefully can help them stop accusing us of stealing OpenOffice.org and engaging in illegal activities when all we do is exercise our rights under the LGPL license.

ed

One thing to note is that the Microsoft XML formats and schemas, either those exported by TextEdit or by the .docx format, are not necessarily done by Microsoft by choice. They're not even in response to OpenOffice.org. In my opinion, they are the result of "government forced technology", similar to how the California clean air regulations back in the 70s started to force Detroit to pour more money into catalytic converters and environmentally friendly cars.

There have been numerous government proposals and mandates that require open document formats. Some of the Massachusetts proposals come to mind. I believe the EU also has proposals on the table that require the use of open document formats. The trick with the EU proposal is that it actually mentioned XML (I believe it's the ISIS proposal, but may have the wrong acronym). Governments are large Microsoft customers and Microsoft doesn't want to lose their business. Including the ability to save in publicly documented XML formats gives them a loophole to continue selling to governments, even if all of the open document format requirements are adopted.

The ability of OpenOffice.org (and NeoOffice/J) to support these formats really is dependent on two things. First, the schemas are licensed from Microsoft on non-OSS compatible terms. Each individual person or application has to enter into a licensing agreement with Microsoft individually. This is directly against the terms of either BSD style or GPL style licensing. Secondly, Microsoft may have software patents involved with their schemas according to their licensing terms. While the patentability of a schema itself is questionable, they seem to have several patents revolving around the interpretation of XML schemas that may apply to their Office schemas. This goes against the CDDL style licensing Sun is now fond of.

Because of these terms, the only ways that OOo/NeoOffice could legally support them would be if either the schemas are clean room reverse engineered from example documents or if Microsoft turns a blind eye to open source folk using their schemas. Since I wouldn't want to rely on Microsoft's generosity, the clean room solution is the only way I can see. Sun won't be the one to clean room them either; they don't have to. StarOffice (and Sun built OpenOffice.org for Linux/Solaris/Win) would be covered under Sun's cross-licensing arrangements with Microsoft as a result of their settlement. Those licenses don't extend to non-Sun OOo developers like me, however, so we're all up shit creek.

Just because you can read it and the format is "open" doesn't mean it's "free". You can be sure that Microsoft's lobbyists will make sure that all of those government directives still refer to "open" and no "free" gets snuck in there by mistake.

ed

From the NeoJ Forum

The Java that's used within NeoJ is "pure" Java, AWT and Java 2D at present, and perhaps some Swing in the future. Anything that's using OS X specific frameworks is written in either C++ or Obj-C. Since the majority of the application is already C++ based, we just call the frameworks directly. There's no need for us to add an extra layer with the CocoaJava language bridge and never will be.

Ouch. I wonder what that means for an OOo 2.0 (and beyond) version of NeoOffice/J?
http://www.neooffice.org/

I'm no programmer, however isn't Java's appeal the fact that it's very easy to make Java apps cross-platform?

While Sun's intentions in open sourcing their products may not be neccesarily benign, they ARE giving *something significant* to the open source communuity. The best example I can give is OpenOffice.

Sun does have it's own commercial office suite called StarOffice which is derived from the OO suite, however OO is being developed into a very well-rounded competitor.

NeoOffice/J for OS X is a great opensource alternative for MS Office, and that project has its roots in the OpenOffice suite.

First comes stability, then beautification :)

There's a plan underway to redo the GUI icons, and eventually we hope to force OOo to realize that the UI matters and more than just swapping icons and buttons are needed....

Will that be a huge setback to the project, or will they just be able to check a box and recompile, as Steve Jobs suggested in his keynote?

Sounds like it'll 'simply' (heh) involve porting to GCC4...

What they really need is (a) more programmers with some highly esoteric combinations of skills, (b) a Mac-Intel box or two, and (c) monetary donations! :-)

Implement Aqua widgets and file dialogs - This has been our goal for a long time and I would like to get this done while the OpenOffice.org volunteers are working out all of the bugs in the OpenOffice.org 2.0 X11 code.

I have an iBook. I like my iBook. i like my ibook because it allows me to write my books (using NeoOffice) at places other than my desk. But that's it. If I were to have to purchase all the equivalent software for my ibook that i use on my Linux desktop - I, well, I couldn't because I'm a starving artist.

So Linux won't suffer from OS X moving to x86 software. The same people that use Linux will continue to use Linux.

Besides - the reason a lot of people use OS X is because of the sexy hardware it runs on. x86 hardware (unless you're getting it from alienware or something) is just blah.

Free software (GIMP, OpenOffice) is possible with lots of effort if you're an expert.

Heard of NeoOffice/J? If you can't install/run that, then I don't know what you're doing on an OS X box...

As for the GIMP, http://gimp-app.sourceforge.net/ is your friend along with Apple's X11, which is as easy to install as anything else from Apple.

I don't really see the problem here...

And "no configuration options"? C'mon...

Well, I was involved with this on a number of levels and can say there was no announcement. What happened was a slip up and spin control. The original article contained quotes that were taken from the end of an interview with Tony Siress on a completely different topic. He was mostly talking about OpenOffice.org on Mac OS X. Note the quote that was interpreted as being the "announcement" of a cooperation:

"I don't want to sell StarOffice for OS X," Siress said. "I want Apple to bundle it. I'll give them the code. I'd love it if I could get the team at Apple to do joint development and they distribute it at no cost--that it's their product. Nobody makes a product more beautiful on Apple than Apple."

Does that sound like a product and bundling announcement? Hell no. It was Tony going off on what he'd "like" to happen, that he'd "like" to have a partnership with Apple and a bundling deal. It never existed. The StarOffice team that he was talking about was the one that existed under Patrick Luby back in 2000 prior to when Sun open sourced the failed remnants of the Mac port.

It also turns out that by this time Patrick had already been working on NeoOffice/J and, being a former Sun employee and manager of the Mac port, he was beginning to show early versions of his application to people within Sun. This is one of the projects that was mentioned by Sun managers as the Java port, even though it wasn't even a Sun project. Tony himself referenced NeoOffice/J's ancestor in his interview.

Tony later explained the mixup to the OOo community, which was later picked up by the press. He was talking out his ass and made my life hell for a whole week.

CNet was embarassed, of course, since they essentially now looked like fools by "breaking" completly false information. So they ran a counter-argument story that had longer quotes from the interview. The Quartz version that he's referring to was the Quartz porting work I had been doing in OpenOffice.org. The Java version he's referring to was the early work by Patrick. It even had some quotes from a Sun PR person confirming that Tony said what he had said. Sun PR sacrificed Tony to maintain a working relationship with CNet (apparently there had been a Sun PR person involved with the original interview but they hadn't stopped Tony from making off-topic comments).

The key point you'll see in that "refutation" article that makes it known he's full of it is the quote on laptops at the bottom. He mentions Apple wanting to sell Sun PowerBooks. His "contact" at Apple was a sales rep who was trying to sell laptops, not an engineer!

After that fun blunder, Tony never really was allowed to speak to the press again, particularly on StarOffice related issues.

Conspiracy theorists love making a big deal out of this up until this day (witness the parent), but in the end it was all a bunch of bull caused by an eager manager and an overexuberant reporter "breaking" a supposed story without doing any fact checking to confirm the horseshit coming out of the manager's mouth.

The good thing was that it pissed me and Dan off so much we created the NeoOffice project (NeoOffice/C) to prove it could be done. Eventually Patrick was convinced to open source the code Tony referred to and thus NeoOffice/J was born. Bad thing is it wrecked any chance of Sun or Apple actually providing OpenOffice.org engineering support since the PR n

Well, I was involved with this on a number of levels and can say there was no announcement. What happened was a slip up and spin control. The original article contained quotes that were taken from the end of an interview with Tony Siress on a completely different topic. He was mostly talking about OpenOffice.org on Mac OS X. Note the quote that was interpreted as being the "announcement" of a cooperation:

"I don't want to sell StarOffice for OS X," Siress said. "I want Apple to bundle it. I'll give them the code. I'd love it if I could get the team at Apple to do joint development and they distribute it at no cost--that it's their product. Nobody makes a product more beautiful on Apple than Apple."

Does that sound like a product and bundling announcement? Hell no. It was Tony going off on what he'd "like" to happen, that he'd "like" to have a partnership with Apple and a bundling deal. It never existed. The StarOffice team that he was talking about was the one that existed under Patrick Luby back in 2000 prior to when Sun open sourced the failed remnants of the Mac port.

It also turns out that by this time Patrick had already been working on NeoOffice/J and, being a former Sun employee and manager of the Mac port, he was beginning to show early versions of his application to people within Sun. This is one of the projects that was mentioned by Sun managers as the Java port, even though it wasn't even a Sun project. Tony himself referenced NeoOffice/J's ancestor in his interview.

Tony later explained the mixup to the OOo community, which was later picked up by the press. He was talking out his ass and made my life hell for a whole week.

CNet was embarassed, of course, since they essentially now looked like fools by "breaking" completly false information. So they ran a counter-argument story that had longer quotes from the interview. The Quartz version that he's referring to was the Quartz porting work I had been doing in OpenOffice.org. The Java version he's referring to was the early work by Patrick. It even had some quotes from a Sun PR person confirming that Tony said what he had said. Sun PR sacrificed Tony to maintain a working relationship with CNet (apparently there had been a Sun PR person involved with the original interview but they hadn't stopped Tony from making off-topic comments).

The key point you'll see in that "refutation" article that makes it known he's full of it is the quote on laptops at the bottom. He mentions Apple wanting to sell Sun PowerBooks. His "contact" at Apple was a sales rep who was trying to sell laptops, not an engineer!

After that fun blunder, Tony never really was allowed to speak to the press again, particularly on StarOffice related issues.

Conspiracy theorists love making a big deal out of this up until this day (witness the parent), but in the end it was all a bunch of bull caused by an eager manager and an overexuberant reporter "breaking" a supposed story without doing any fact checking to confirm the horseshit coming out of the manager's mouth.

The good thing was that it pissed me and Dan off so much we created the NeoOffice project (NeoOffice/C) to prove it could be done. Eventually Patrick was convinced to open source the code Tony referred to and thus NeoOffice/J was born. Bad thing is it wrecked any chance of Sun or Apple actually providing OpenOffice.org engineering support since the PR n

Using OO on a Mac works, but not as well as a native OS X app would

What about NeoOffice? Has anybody tried to do some real-world work with this suite? They have a three phase roadmap aimed at NeoOffice becoming a truly native app complete with the Aqua look and feel.

That said, it still is nowhere near a nice player on OSX, but it's the best you can get unless you want to pay for MS Office or Pages.

Yes, the code is ugly. After all, it is over 10 years old now as it was originally written by Star Division. You can still see legacy stuff from StarOffice 4 in the CVS repository including OS/2 code :) It's been a double-edged sword. Because the program is "mature", it's got enough of a feature set that folks can start to consider it on the level of Microsoft Office (well, it's probably more like the old Lotus suite kind of level...ironic since IBM just replaced parts of Workplace with OpenOffice.org). On the other hand, because it's so old the code can get really messy and be a bear to deal with. Ever since 2001 it's been near a full time job just to keep the application compiling, and it's still ongoing with OOo 2.0. Parts of it are wholly undocumented and the original authors are long gone.

The interface itself is a larger issue. It's written in custom tools that are used by no other product, and there are hundreds of dialogs alone (perhaps thousands, I haven't counted). And nearly none of this interface meets Apple HIG since it was designed for Windows and Unix (which, as we know, has nearly no UI guidelines at all). Because of that, and also because of the sheer largesse of the interface itself, the only way I could see Apple using OOo would be through writing a "wrapper", that is, junking the existing interface and writing a new one.

Since Apple already has core rendering engines for word processing documents, presentations, and charts, it seems all they need is a spreadsheet engine and they'd already cover the stock OOo core. It'd probably be easier to just write the new wrapper around their existing components and add in the missing functionality (e.g. database, macros) than to wrestle with OOo. All the better for them, too, since I bet they already have a core that was written with Objective-C in mind...

ed

NeoOffice/J is fairly integrated with the Mac OS X environment and isn't a Java application. While we don't use services and we don't use native UI elements other than menus yet, there are a number of points on which you are mistaken:

• NeoOffice/J is feature-equivalent to OpenOffice.org 1.1.4. NeoOffice/J is built directly on top of OpenOffice.org Mac OS X (X11) version 1.1.4 and is missing no features present in the X11 version. We only extend, we don't remove.
• NeoOffice/J is not a Java application. 98% of NeoOffice/J is written in C++ and is taken straight from OpenOffice.org. The Java components comprise less than 2% of the codebase. All of the performance issues that people complain about are in the C++ code, not the Java code. In fact, the Java code can be faster than the X11 code in a number of instances, particularly with menus.
• NeoOffice/J is integrated into the Mac OS X environment. While you cite the things we haven't implemented yet, you fail to mention the ways in which NeoOffice/J integrates with Mac OS X that the X11 version does not, including:
  • Spotlight indexing in 10.4
  • Pritnts using native print drivers and print dialog
  • Native fonts, font layout, and kerning
  • Native antialiasing
  • Double-clickable application bundle
  • Exchange of text and images via the Clipboard
  • Native Aqua menus in the standard Mac menubar
  • Automatic user interface translation based upon language preference
  • Dock menu for creating and opening documents
  • Integrates with Mac OS X mail applications like Mail.app and Entourage.
  • Installs using the standard Apple Installer application.
  • Can open Office documents based on type/creator codes.

  I'm sure I'm missing a few others as well.

Citing things that the integration is lacking is not a sufficient way of proving NeoOffice/J isnt' integrated. By an equivalent argument, Photoshop doesn't offer Spotlight integration for searching layers of its files, so it can't obviously be an integrated Mac OS X application. Before saying that NeoOffice/J isn't integrated perhaps you should do a little homework instead :)

ed

NeoOffice/J is fairly integrated with the Mac OS X environment and isn't a Java application. While we don't use services and we don't use native UI elements other than menus yet, there are a number of points on which you are mistaken:

• NeoOffice/J is feature-equivalent to OpenOffice.org 1.1.4. NeoOffice/J is built directly on top of OpenOffice.org Mac OS X (X11) version 1.1.4 and is missing no features present in the X11 version. We only extend, we don't remove.
• NeoOffice/J is not a Java application. 98% of NeoOffice/J is written in C++ and is taken straight from OpenOffice.org. The Java components comprise less than 2% of the codebase. All of the performance issues that people complain about are in the C++ code, not the Java code. In fact, the Java code can be faster than the X11 code in a number of instances, particularly with menus.
• NeoOffice/J is integrated into the Mac OS X environment. While you cite the things we haven't implemented yet, you fail to mention the ways in which NeoOffice/J integrates with Mac OS X that the X11 version does not, including:
  • Spotlight indexing in 10.4
  • Pritnts using native print drivers and print dialog
  • Native fonts, font layout, and kerning
  • Native antialiasing
  • Double-clickable application bundle
  • Exchange of text and images via the Clipboard
  • Native Aqua menus in the standard Mac menubar
  • Automatic user interface translation based upon language preference
  • Dock menu for creating and opening documents
  • Integrates with Mac OS X mail applications like Mail.app and Entourage.
  • Installs using the standard Apple Installer application.
  • Can open Office documents based on type/creator codes.

  I'm sure I'm missing a few others as well.

Citing things that the integration is lacking is not a sufficient way of proving NeoOffice/J isnt' integrated. By an equivalent argument, Photoshop doesn't offer Spotlight integration for searching layers of its files, so it can't obviously be an integrated Mac OS X application. Before saying that NeoOffice/J isn't integrated perhaps you should do a little homework instead :)

ed

Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project.

Quote: Couldn't Apple do this building from the 2.0 code base?

The short answer is no. It is a common misconception that the OOo 2.0 codebase eases any transition to a native interface. This is far from the truth. Take the GTK "look" in 2.0. The fact that it looks like GTK does not mean that the interface has been redone in GTK. Rather, the OpenOffice VCL widget set has been enhanced to work similar to the Java heavyweight peer implementation. OOo instructs the platform to draw a button according to its native platform appearance. All of the event handling still uses the abstract OOo toolkit.

Since everything still uses the native toolkit, you still need to port the underlying OOo widget set and toolkit to run on the platform. OOo 2.0 only provides this for X11 and for Win32. NeoOffice/J provides an implementation in a mixture of Java and Carbon (soon to be Java and Cocoa). Getting it right is a nightmare. It's taken three years and thousands of hours of developer time.

And we still don't have the native widget drawing stuff...but it's on the way.

There are other reasons why Apple wouldn't start from OOo 2.0. First off, Microsoft Office is one of the key selling points of the Mac platform that gets reiterated throughout the Mac sales materials and end user testimonials and, I daresay, things like Jobs' keynotes which always have Office demos. It's politics, of course, but Apple will most likely not start any "Office killer" application that may cause Microsoft to stop working on Office.

Secondly, Apple's already got their iWork suite. It's been designed as a consumer level and home office suite. Quite a bit of work has gone into rethinking the traditional office interfaces for Pages and Keynote. Most likely there's a spreadsheet application on the way as well. This engineering effort is not going to be simply discarded in favor of OpenOffice.org. iWork is also better suited towards their consumer-oriented strategy.

Additionally, KHTML is a great example of why Apple would not jump on the OpenOffice.org bandwagon. If you recall, the reason KHTML was chosen over Mozilla was because the engineers thought that the Mozilla codebase was unwieldly. I've programmed both Mozilla and OpenOffice.org for years and the Mozilla code looks easy when compared to OOo. And Mozilla is even commented in English, too. If they didn't want to work with the Mozilla code, you can bet they won't want to touch OOo with a 10 foot pole.

I've toiled on OpenOffice.org and NeoOffice/J on Mac OS X for nearly four years now. If Apple hasn't helped by now, I doubt they will so in the future.

ed

Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project.

Quote: Couldn't Apple do this building from the 2.0 code base?

The short answer is no. It is a common misconception that the OOo 2.0 codebase eases any transition to a native interface. This is far from the truth. Take the GTK "look" in 2.0. The fact that it looks like GTK does not mean that the interface has been redone in GTK. Rather, the OpenOffice VCL widget set has been enhanced to work similar to the Java heavyweight peer implementation. OOo instructs the platform to draw a button according to its native platform appearance. All of the event handling still uses the abstract OOo toolkit.

Since everything still uses the native toolkit, you still need to port the underlying OOo widget set and toolkit to run on the platform. OOo 2.0 only provides this for X11 and for Win32. NeoOffice/J provides an implementation in a mixture of Java and Carbon (soon to be Java and Cocoa). Getting it right is a nightmare. It's taken three years and thousands of hours of developer time.

And we still don't have the native widget drawing stuff...but it's on the way.

There are other reasons why Apple wouldn't start from OOo 2.0. First off, Microsoft Office is one of the key selling points of the Mac platform that gets reiterated throughout the Mac sales materials and end user testimonials and, I daresay, things like Jobs' keynotes which always have Office demos. It's politics, of course, but Apple will most likely not start any "Office killer" application that may cause Microsoft to stop working on Office.

Secondly, Apple's already got their iWork suite. It's been designed as a consumer level and home office suite. Quite a bit of work has gone into rethinking the traditional office interfaces for Pages and Keynote. Most likely there's a spreadsheet application on the way as well. This engineering effort is not going to be simply discarded in favor of OpenOffice.org. iWork is also better suited towards their consumer-oriented strategy.

Additionally, KHTML is a great example of why Apple would not jump on the OpenOffice.org bandwagon. If you recall, the reason KHTML was chosen over Mozilla was because the engineers thought that the Mozilla codebase was unwieldly. I've programmed both Mozilla and OpenOffice.org for years and the Mozilla code looks easy when compared to OOo. And Mozilla is even commented in English, too. If they didn't want to work with the Mozilla code, you can bet they won't want to touch OOo with a 10 foot pole.

I've toiled on OpenOffice.org and NeoOffice/J on Mac OS X for nearly four years now. If Apple hasn't helped by now, I doubt they will so in the future.

ed

Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project.

Quote: Couldn't Apple do this building from the 2.0 code base?

The short answer is no. It is a common misconception that the OOo 2.0 codebase eases any transition to a native interface. This is far from the truth. Take the GTK "look" in 2.0. The fact that it looks like GTK does not mean that the interface has been redone in GTK. Rather, the OpenOffice VCL widget set has been enhanced to work similar to the Java heavyweight peer implementation. OOo instructs the platform to draw a button according to its native platform appearance. All of the event handling still uses the abstract OOo toolkit.

Since everything still uses the native toolkit, you still need to port the underlying OOo widget set and toolkit to run on the platform. OOo 2.0 only provides this for X11 and for Win32. NeoOffice/J provides an implementation in a mixture of Java and Carbon (soon to be Java and Cocoa). Getting it right is a nightmare. It's taken three years and thousands of hours of developer time.

And we still don't have the native widget drawing stuff...but it's on the way.

There are other reasons why Apple wouldn't start from OOo 2.0. First off, Microsoft Office is one of the key selling points of the Mac platform that gets reiterated throughout the Mac sales materials and end user testimonials and, I daresay, things like Jobs' keynotes which always have Office demos. It's politics, of course, but Apple will most likely not start any "Office killer" application that may cause Microsoft to stop working on Office.

Secondly, Apple's already got their iWork suite. It's been designed as a consumer level and home office suite. Quite a bit of work has gone into rethinking the traditional office interfaces for Pages and Keynote. Most likely there's a spreadsheet application on the way as well. This engineering effort is not going to be simply discarded in favor of OpenOffice.org. iWork is also better suited towards their consumer-oriented strategy.

Additionally, KHTML is a great example of why Apple would not jump on the OpenOffice.org bandwagon. If you recall, the reason KHTML was chosen over Mozilla was because the engineers thought that the Mozilla codebase was unwieldly. I've programmed both Mozilla and OpenOffice.org for years and the Mozilla code looks easy when compared to OOo. And Mozilla is even commented in English, too. If they didn't want to work with the Mozilla code, you can bet they won't want to touch OOo with a 10 foot pole.

I've toiled on OpenOffice.org and NeoOffice/J on Mac OS X for nearly four years now. If Apple hasn't helped by now, I doubt they will so in the future.

ed

Disclaimer: I am a Mac OS X OpenOffice.org contributor and a founder of the NeoOffice project.

While this is a troll, I'll bite. Neither NeoOffice/J nor OpenOffice.org Mac OS X (X11) has reimplemented the interface...yet. The reason is perfectly logical. It took over three years just to get the core application to work as expected, that is, it can print using native print drivers, use native fonts, automatically translate itself, and do so without crashing. As I learned from previous hack attempts, the hard part is getting this large application to work properly at all.

When it comes down to it, having pretty buttons is really not as important as having an application that is rock-solid stable and can be used in a production environment.

Now that we have one, we can start adding in the pretty buttons. Instead of flaming, perhaps you should read up on our 2005 NeoOffice/J development plans and you'd see that native widgets are near the top of the list. Even better, why not help find some volunteer developers to help spread the load?

ed

Disclaimer: I am a Mac OS X OpenOffice.org contributor and a founder of the NeoOffice project.

While this is a troll, I'll bite. Neither NeoOffice/J nor OpenOffice.org Mac OS X (X11) has reimplemented the interface...yet. The reason is perfectly logical. It took over three years just to get the core application to work as expected, that is, it can print using native print drivers, use native fonts, automatically translate itself, and do so without crashing. As I learned from previous hack attempts, the hard part is getting this large application to work properly at all.

When it comes down to it, having pretty buttons is really not as important as having an application that is rock-solid stable and can be used in a production environment.

Now that we have one, we can start adding in the pretty buttons. Instead of flaming, perhaps you should read up on our 2005 NeoOffice/J development plans and you'd see that native widgets are near the top of the list. Even better, why not help find some volunteer developers to help spread the load?

ed

" OpenOffice will never be an Office killer on OS X until it is a native app"

This is the inevitable "what about NeoOffice?" response.
I don't use MS Office on my Mac, and it offended me like a whiff of bowel gas whenever the MS OfficeX trial agreement would pop up whenever I tried to open a file. I think I reassigned most of the extentions to the proper application now, but it was still annoying.

http://www.neooffice.org/

He might have meant NeoOffice/J, which is a Java port of OpenOffice that behaves a bit more like a native OS X app than the X11 version (which really sucks, I have to say).

.. you can't really compare Open Office and MS Office, since OO doesn't run natively on OS X.

Try NeoOffice based on OO.o code, but with a native aqua interface.

Here is a link to neoOffice, Open office for OS X

http://www.neooffice.org/

Actually it has been. Check out NeoOffice. It looks like the same old crappy OpenOffice interface without the need for X11. I don't really care though since I have a copy of Office X which works fine. :-)

Disclaimer: I am an OpenOffice.org Mac OS X devleoper and a founder of the NeoOffice project

Quote: This means OpenOffice.org 2.0 will work *now*. This means no more second-class Mac versions of popular OS apps.

This statement couldn't actually be farther from the truth. In fact, it will actually make the push for OpenOffice.org, at least, more difficult. If you dig into the details it means there's much more work ahead:

• Most Unix based apps don't use XCode. Just about all Linux and Unix derived applications use command line build systems. According to the information from Apple, universal binary support only applies to XCode based projects. With hundreds of thousands of files and a custom build system, it would take years just to get OpenOffice.org to build with XCode and it may not even be possible.
• Delivery of fat binaries is impractical for large open source applications. A single platform binary of OOo already clocks in at greater than 100 MB. People already complain about that size. A true integrated universal binary would probably close to double that size (though perhaps less due to use of cisc). Downloaders will love that.
• To compile will require the use of GCC 4.0. I don't know about other projects, but moving OpenOffice.org to new GCC versions is a real pain in the butt. Code doesn't compile, options change, the way things link change, but, more importantly...
• Apple is using their own ABI. OpenOffice.org requires knowledge of the ABI in order to get UNO objects to communicate (the OOo incarnation of COM). This ABI glue is coded in assembly and is unique for each compiler on each architecture (e.g. the gcc 2 C++ ABI is different from 3, which is different from 4, etc.). Since Apple is using their own ABI, code from Linux or Windows can't simply be moved over even if it is the same compiler. No work can begin on an Intel port until the ABI is solidified.
• Linux apps don't use Carbon/Cocoa. The transition to a native OpenOffice.org will still require the type of work we're doing in the NeoOffice project, the piecemeal replacement of X11 dependencies with native code. Most people who speak of a native OOo on a Mac don't give a hoot about X11, they want the one with the blue buttons.
• Apple isn't offering hardware to people not in their developer programs. Few contributors to open source projects have funds already, but the fact that one has to be a member of one of their paying developer programs will make it even more difficult for Mac open source contributors to get a grasp on the Intel switch. It was bad enough with Tiger where we didn't have access to test things before it got released, and that was just software!

Changing processors does nothing to help OpenOffice.org development on Mac OS X except slow it down yet again. Chances are you'll probably see it running in an emulator for a long time before it's running on Mactel hardware.

ed

I can't think of a better place, except perhaps the two developers of NeoOffice/J, one of whom is now having to take a break from development due to economic concerns...

I still have my doubts if it'll ever come out for OS X (and yes, I know it'll run in X11, and no, that doesn't count).

I beg your pardon:

NeoOffice/J

for OS X is rock solid. No X11 needed. Two grad papers I recently turned in were written using this, with advanced charts and tables, headers, footers, etc. Works fine in 10.4 Tiger also.

The release times are dfiferent primarily because we have different priorities. It's difficult enough to work out all the bugs in our existing graphics layer. Moving to 2.0 requires significant amounts of re-engineering, yet again. There are also a number of equivalent major tasks that have to be weighed against each other:

• Getting things stable enough so we can have a Neo/J 1.1 Final release!
• Fixing crashes that occur when operating system updates occur
• Getting font layouts to match other Mac applications (this has taken years already and is still not perfect)
• Adding in Aqua widgets beyond menus
• Integrate with standard Mac OS X file dialogs
• Continuing to support all of our supported languages (2.0 hasn't been fully translated yet)
• Moving to Java 1.5 (requires moving from Carbon to Cocoa)

All of these tasks are at least as complicated as moving to 2.0. We've decided that higher priorities are getting to our Final release and improving our Mac OS X integration with things like our Spotlight & Aqua control integration. If someone really needs a 2.0 feature, the X11 version will be available for them to use. We'll start using 2.0 in Neo/J eventually, but it's going to require a lot of engineering and, being two people, we don't have the time.

For some more info you can check out this forum thread. There's some more stuff in previous /. comments I've posted as well.

ed

Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.

One of the biggest reasons behind the SISSL license is of course StarOffice. When Sun open sourced StarOffice, not all of the code could be opened due to licensing agreements or third party contracts. Two prime examples are the dictionaries and spellcheckers in StarOffice 6 (L&H, I believe...they were replaced in OOo by Kevin H.'s spelling libraries) and the WordPerfect filters of StarOffice 6 (just finishing being replicated in an open source fashion).

So it's slightly different then Mozilla and Netscape...it was more of a solution that allowed them to open source as much of SO as possible without having to cripple their commercial product by removing code that was incompatible with the open soruce license. While all of the development is essentially publicly accessible (unlike Netscape), the SISSL license is still required to allow all of the contracted libraries to be included in the final commercial StarOffice product.

Originally OpenOffice.org was going to be released under the SISSL license only. LGPL was actually thrown in as an afterthought by the now departed former head of StarDiv. I'm glad it was since it let me make the transition to full GPL to avoid all of the closed source proprietary nonsense that SISSL allows :)

ed

Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.

One thing about Neo is that we've never marketed it as a replacement for Office.mac. We've never marketed it really at all. You'll also find that we're very candid about saying that folks who want a great Mac experience should go out and buy Office.mac and that really, for its price, Office.mac is quite a good deal.

I personally enjoy using Neo because I don't have to worry about going to edit a document with Office.mac only to try to launch it and find out all of our licenses are in use on the network. Since I kicked Office.mac off of my machine I've never lost productivity due to someone forgetting to quit Word on another machine. I've also never had to rummage through to find a CD key when installing it on new partitions, portables, etc. and have never caught a Word macro virus from all of the infected files that run around as attachments in my e-mail folder.

Enjoyment is always relative to ones' needs, I guess. Office:mac is quite enjoyable, though, and I highly recommend it. It's nicer than the Windows Office versions, IMHO.

ed

Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.

I personally agree with the parent...marketing something that's not yet ready is a horrible idea and bad impressions have worse long term damage than no impressions at all. Part of the problem lies with the way that OpenOffice.org was built as a community. Unlike Linux and some other FOSS projects, the community wasn't built up around engineers. There are very few engineers outside of Sun that actually are real major contributors to the project.

The OOo community was built around marketing. Finding community members to assist with marketing was one of the first and most successful community building drives for OOo. The marketing community behind OOo has done some amazing things and may be the reason why OOo has such mindshare over other open source office suites like KOffice (and Sun marketing has helped push OOo as well).

Honestly, OOo didn't get as recognized as it is today due to its underlying technical merit. It got there as the result of a lot of hard work by that marketing community. If any fault can be found, it may just be that they are overexuberant about OOo and may oversell it at times.

Neo's slightly different in that it was founded by engineers. There's no marketing push for Neo in any kind of organized fashion. There's no money spent on marketing it at all (all donations go to host our servers and for helping allow Patrick to work on it full-time). It's technical merit over OOo X11 is the only reason why it's known today. To me that seems like the logical path for FOSS.

I really don't see the necessity in marketing something that's free.

ed