Disclaimer: I am one of the founders of NeoOffice.
Being based on OOo 1.x, IBM does not need to release the source code for Symphony. OOo was originally dual licensed both under LGPL and the SISSL license. SISSL allows companies to make completely closed source forks, only providing notice of the original vendor and SISSL license. This license was one of the primary motivating factors for why we forked and created NeoOffice, to prevent companies from making a commercial product whose improvements couldn't be shared back with all the volunteers that had worked to create it.
Closed source forking is also our reason for using full GPL since it guarantees everyone's freedom to access the code. Not even LGPL provides that ability since commercial closed source proprietary code can still be incorporated provided it's in a shared library. Only the full GPL provides enough protections to ensure that everyone must cooperate and that no one can make key parts of the project rely on closed source solutions.
Disclaimer: I am a founder of the NeoOffice project.
ooo-build has long been much more than build fixes. For many years it has been the public face of the work Ximian and Novell have poured into the OpenOffice.org source base. It has a long history of features that Ximian/Novell have helped develop, including (but not limited to):
OpenXML import/export support via odf-converter
Kohei's solver optimization extension
Native widget framework and GNOME integration (from back in 1.1.x)
Visual Basic suport for Calc
Alpha-blending and enhanced alpha blended icons
A redesigned GNOME-like icon set
Microsoft Works importer
Evolution integration
And more...
ooo-build is about functionality and features. Despite the name, it has never been about "build fixes" as indicated in the article. The additional functionality is so awesome that, at NeoOffice, we have been using ooo-build in NeoOffice since March and have been donating back bug fixes and Mac-specific support patches to the ooo-build project. Years ago the Ximian work on OOo 1.0.3 was so promising that I put together a Mac OS X port back in 2003 which folks used for a long time. OxygenOffice also is based off of the ooo-build project (although I do not know if the OOOP team coordinates with ooo-build).
The ooo-build team has done amazing work. It is sad to see their work go unrecognized by so many and be outright rejected or stalled by Sun. NeoOffice users have loved having the functionality ooo-build brings currently and continues to bring in the future, and much of the work pioneered by ooo-build is critical to maintaining the Mac platform as a viable office solution (read VBA). Sun's lack of acknowledgement and incorporation of ooo-build features does nothing but hurt users. Having received a "you're welcome to join us" response similar to Kohei, I am glad I do not consider myself part of OOo any longer. The freedom of forking has allowed NeoOffice to incorporate all good code without all of these politics and marketing games. Forking has allowed NeoOffice to deliver to Mac users the features they wanted yesterday regardless of where those features came from. Sun has a history of a "not invented here" syndrome at times when it comes to code within their "open" source projects.
I'm glad to see that ooo-build is getting some recognition. I hope more users start seeing some of the great functionality they can get today on Windows and Linux, and once again I thank ooo-build, Ximian, and Novell for their continued dedication to improving OOo.
Disclaimer: I am one of the founders of NeoOffice.
I think there's already interesting proof that forks can provide a very viable alternative to the overhead of the OOo project. Although the reasons are many, one of the big problems I historically had as a Mac OOo engineer was trying to get patches approved by Sun engineering. It has proven to be more efficient to have engineering freedom, allowing us to implement things that might never be approved by Hamburg. Being independent also has allowed us to implement a binary patching system so our bug fixes can be delivered quickly and independently if any marketing driven release schedules. Being outside the politics has also allowed us to integrate other open source technologies into the application that are important to Mac users, such as VBA support as well as OpenXML import and export. Yes, OpenXML import and export could be integrated into OOo today but engineering politics and Sun's manipulation of the project to foment a document format war have kept this functionality out of OOo, doing nothing except harm users that need to seamlessly integrate with MS Office environments.
NeoOffice has been shipping a solid, native, GPL licensed Mac product for over 2 whole years. We have shown forking is successful. Dropping the politics of the OOo organization has made us more efficient and resulted in a better product that users appreciate. We have had a free software solution for Mac for years, and all OOo has done is exorcise all reference to us from their website. Perhaps it is just banishment for daring to do things differently and not helping to propogate the name of OOo (which Jonathan Schwartz has publicly said is Sun's second most valuable brand after Java). Seems a bit like Sun wants control to me. It will be interesting to see if Sun has the stones to snub IBM for its Lotus Symphony brand in the same fashion.
Disclaimer: I am a founder of the NeoOffice project.
The reason to include the source code is both moral and practical.
From a practical standpoint, it ensures that everyone providing NeoOffice needs to take no special action to comply with the GPL. According to our interpretation, anyone who provides a binary that is licensed under GPL is also obligated to provide the source code for that program. By placing the source code package within our disk images, anyone and everyone who provides the disk images is automatically providing source code. Everyone is fully compliant with even the strictist interpretation of the GPL without needing to do any extra work. This removes a lot of potential hassles and liability for our mirrors and other distributors.
From a moral standpoint, the origin of freedom within free software is the code. The GPL applies to the code, not the binaries; you can't license a binary under GPL without licensing the code. The source code is the freedom. It is worth a few extra bits to give everyone their freedom, even if they choose never to exercise it. Even if our servers go dark, everyone automatically has the source. Anyone can always exercise their rights, guaranteed. No one can ever take that freedom away from them besides themselves.
I think removing some of the pointless drivel on YouTube might be a better way to spare bandwidth and be "kinder to the Internet" rather than removing the guarantee of people's freedom. Perhaps I am just a purist.
Disclaimer: I am a founder of the NeoOffice project.
Quote: and became an even worse idea when Apple deprecated the Java-Cocoa bridge
We never used the CocoaJava bridge at all. I guess you never bothered to read the source code. In fact, we use very little Java at all as is pointed out by the ohloh source code analysis of our open CVS. There's little Objective-C as we do most of the logic in C++ and call out to ObjC when required. There are some other stats there you may find intriguing as well like the estimated man-years and cost it will take to approximate our code.
Trust me, once any OS X port of OOo starts getting font handling and input methods correct, it'll slow down as well. This is true especially for Asian and other foreign languages. The bottleneck is in Apple's ATSUI and how it mismatches to the underlying OOo code. Has nothing to do with Java at all. Speed in a vaporware demo is one thing; carrying speed into a functional product is something different completely.
Due to politics, OpenOffice.org has exorcised all reference that a perfectly functional, native, and Aqua port of OpenOffice.org exists for the Macintosh. It is called NeoOffice. If you want to use only software named "OpenOffice" on your Mac, yes, you have few options, but if you like GPL software go check out the real deal.
NeoOffice 2.1 is scheduled for release on March 27th. Not only do we continue to push forward with being the only truly native fully released Aqua-enabled office application suite for Mac OS X, there are several features included that aren't even in OOo on Linux, including:
Word OpenXML document import and export
Excel VBA macro compatibility
Microsoft Works file import/export
linear programming extensions for Calc
NeoOffice is a GPL project and incorporates the best everyone has to offer to create the best product we can for our users.
OpenOffice.org is a political machine and to meet its own political goals is willing to restrict its users from compatibility requirements like OpenXML and VBA compatibility, not to mention failing to let users know other open source projects exist and are ready now, unlike their Macintosh vaporware. Their own users are hurt by their own desires for personal and political gain.
NeoOffice is free from all corporate influence, is truly GPL free software, and will always be so. If the lack of Mac support is your only reason preventing you from deploying OOo or its derivatives, it's sad that you didn't take the simple time to run a google search and just assumed the information the OOo website was all the larger OOo community has to offer.
The article and the blog linked to it are somewhat trollish since Mac OS X hasn't really had an open kernel for some time. Still, this doesn't affect end useres in the slightest. With the public sources, all that could be built for PowerPC anyway was Darwin which is another BSD derivative. It's not OS X...it doesn't have Quartz, QuickTime, Java, Aqua, the Dock, Carbon, or anything else that makes OS X the operating system that it is. Those components of OS X were never open source and never will be. Where Darwin shined, however, was in opening up the source for drivers.
Some drivers can be made in user space, but a lot of drivers need to be coded in kernel space. When OS X first came out years and years ago, the procedures for writing drivers was horrid. Even today, it's still easy when writing drivers to make a coding error and get a kernel panic. Each kernel panic has a bunch of stuff in the log that allows developers to trace back the problem that caused the kernel to crash.
On PowerPC, the source code for the underlying drivers is available. This is invaluable since not only do you have the point in your code where you have a crash, but you can also figure out what IOKit or the kernel was trying to do that caused the crash. Being able to see exactly how the driver family is using your device is very helpful in figuring out either how to work around your bug or how you can remove it.
With the Intel OS X drivers, however, there is no source. You can't look back and see what the kernel is trying to do that caused your driver to soil itself. This makes debugging a pain in the neck since now, instead of being able to try and figure it out for yourself, you need to get Apple involved if you need more information. Having the PowerPC source isn't sufficient since the drivers are different between x86 and PowerPC. Case in point: right now I'm developing a USB audio device that works just fine on PowerPC but the moment you plug it into an Intel based Mac the OS kernel panics. I suspect a div by zero in the x86 driver, but I can't verify that since I can't see the source. Instead I have to rely on Apple to tell me what to fix.
Thankfully starting with Tiger a number of the more obscure kernel interfaces are actually a bit more abstracted for dlils and the like for which in the past reading kernel code and other drivers was almost the only documentation. That's still no reason for getting rid of the sources.
Although this lack of source is no new development, it really doesn't affect end users. The only people really building custom kernels for running OS X are the XPostFacto guys for running OS X on legacy hardware or PowerPC accelerators, and they never needed x86 code anyway. It affects hardware developers like myself and can make debugging a pain in the neck, especially if you don't have any of those paid-for ADC tech support incidents left.
While Chapter 11 doesn't mean the company is dead (heck, airlines in chapter 11 are even merging these days) it would be very sad to see SGI go. One of the coolest things for me is the single system image computing, for example their Altix single system image supercomputers. High end scientific computing in the US has really thrown its weight behind clustering with off the shelf components (or, in IBM's case, custom components) working together over relatively slow interconnects. While this does work really well for types of problems that can be easily partitioned, not all problems can be easily dispersed. Additionally, many times researchers may not be the most proficient in MPI or other styles of programming that are really key to working well in a clustered system.
Single system image supercomputing offers a way to tackle some problems that can't be partitioned and also to make life easier for scientific programmers who are not well versed in distributed computing theory and practice. It would be a shame to see one of the last companies with that design philosophy disappear along with the technology and will to continue to implement supercomputer designs that don't follow the latest "fad".
Disclaimer: I am an OpenOffice.org developer and a NeoOffice founder.
There are a number of tricks with which you may be able to improve presentation performance. First off, try 1.2 Beta. Older versions of NeoOffice/J were based on Java 1.3. Apple's virtual machine was buggy, so to implement drawing properly we needed to use triple buffering. With NeoOffice 1.2, we're using Java 1.4 and can access drawing buffers directly without working around bugs Apple never fixed in earlier VM versions.
Another thing to keep in mind is that you can always improve speed if you avoid transitions and animations in your presentation. Various funky cube wipes/dissolves add nothing to the content of presentations and just waste everyone's time and (I daresay) distract from the actual content. Folks should focus on what a bullet point actually *says*, not whether it flies in from the right, iris dissolves, or whatever. Sorry if it seems like a rant, but animations really are frills and should be used sparingly. In most every presentation using them, the "transition effects" actually detract from the content instead of providing meaningful information.
I've used NeoOffice and OOo X11 for presentations off of a 400MHz TiBook for years at O'Reilly conferences, business conferences, and others. If someone complains that their presentations run slowly, the first thing that runs through my mind is that it's not the type of presentation I want to be sitting through. Give me an overhead projector with transparancies anyday over something with sound effects and transitions that'll trigger seizures:D
The problem is that those warnings are really runtime errors that will result in crashes in actual application usage. Unlike a lot of gcc warnings, they really can't be ignored and need to be fixed in order to get a running app:)
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:)
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:)
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
Licenses are only part of the problem
on
OpenOffice Goes LGPL
·
· Score: 3, Interesting
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.
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.
Disclaimer: I am a Mac OS X OpenOffice.org developer and a NeoOffice project founder
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.
So the site exists to provide feedback on open source software, but yet all of the RFC documents they provide for public consumption are using Microsoft Office formats. Seems like using OpenDocument or PDF would have been a bit more appropriate. What better introduction could you have to businesses than to let them know the world doesn't revolve around Microsoft Office.
Disclaimer: I am an OpenOffice.org Mac OS X developer and a founder of the NeoOffice project.
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.
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
Disclaimer: I am an OpenOffice.org Mac OS X developer and a founder of the NeoOffice project.
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...
Disclaimer: I am an OpenOffice.org Mac OS X developer and a founder of the NeoOffice project.
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
Re:I can't see this happening anytime soon
on
Dell We'd Sell Mac OS X
·
· Score: 4, Interesting
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.
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?
Pfft, it's worse then dependent on the processor, it's dependent on the *compiler*. The guys who wrote it back in the 90s re-invented COM and devised a language-independent component binding. Good in theory...bad because glue needs to be written for each individual langauge. It needs to be written even for the same language if different compilers have different calling conventions or differnet ways of throwing exceptions. This is roughly the ABI and, according to the documents that Apple made public, they have not yet finalized their x86 ABI.
These are the result of decisions made over a decade ago. OOo is now a 8 million line plus C++ application. It's very difficult, if not impossible to move to another language without a rewrite. Moving it to Java is a highly nontrivial task.
The problem isn't the compiler, it's the build system. All the talk has been of how easy it is to use XCode and how Metrowerks folk (a non-trivial amount of devs) should move to XCode. XCode is not the answer, and for many Unix/Linux derived products may not even be feasible.
Support for delivery on two simultaneous architectures can get quite tricky for projects like OOo. OOo uses its own libraries in a "bootstrapping" process with a fair number of tools built from its own libraries that are used to perform resource compilation, custom makefile languages, check XML validity, etc. as part of the build. It is its own intricate build system that is difficult to replicate with tens of thousands of lines of makefiles. There's no thought given in this process to cross-compilation, and the build system is quite complex and will take some time to figure out.
This "miraculous" 2 hour port that Jobs has convinced all of the users will be possible just isn't. It's sad that the RDF is now being used to unduly pressure developers by stating "half-truths" about how easy this transition will be.
While I'm assuming that the fat binary format will *hopefully* be easy to figure out (like a Mactel subdirectory in the bundle), getting other build systems to build multiple architectures is not necessarily an easy task. If it's dependent on other XCode build procedure specifics it'll just be worse.
Slashdot Mirror
Disclaimer: I am one of the founders of NeoOffice.
Being based on OOo 1.x, IBM does not need to release the source code for Symphony. OOo was originally dual licensed both under LGPL and the SISSL license. SISSL allows companies to make completely closed source forks, only providing notice of the original vendor and SISSL license. This license was one of the primary motivating factors for why we forked and created NeoOffice, to prevent companies from making a commercial product whose improvements couldn't be shared back with all the volunteers that had worked to create it.
Closed source forking is also our reason for using full GPL since it guarantees everyone's freedom to access the code. Not even LGPL provides that ability since commercial closed source proprietary code can still be incorporated provided it's in a shared library. Only the full GPL provides enough protections to ensure that everyone must cooperate and that no one can make key parts of the project rely on closed source solutions.
ed
Disclaimer: I am a founder of the NeoOffice project.
ooo-build has long been much more than build fixes. For many years it has been the public face of the work Ximian and Novell have poured into the OpenOffice.org source base. It has a long history of features that Ximian/Novell have helped develop, including (but not limited to):
ooo-build is about functionality and features. Despite the name, it has never been about "build fixes" as indicated in the article. The additional functionality is so awesome that, at NeoOffice, we have been using ooo-build in NeoOffice since March and have been donating back bug fixes and Mac-specific support patches to the ooo-build project. Years ago the Ximian work on OOo 1.0.3 was so promising that I put together a Mac OS X port back in 2003 which folks used for a long time. OxygenOffice also is based off of the ooo-build project (although I do not know if the OOOP team coordinates with ooo-build).
The ooo-build team has done amazing work. It is sad to see their work go unrecognized by so many and be outright rejected or stalled by Sun. NeoOffice users have loved having the functionality ooo-build brings currently and continues to bring in the future, and much of the work pioneered by ooo-build is critical to maintaining the Mac platform as a viable office solution (read VBA). Sun's lack of acknowledgement and incorporation of ooo-build features does nothing but hurt users. Having received a "you're welcome to join us" response similar to Kohei, I am glad I do not consider myself part of OOo any longer. The freedom of forking has allowed NeoOffice to incorporate all good code without all of these politics and marketing games. Forking has allowed NeoOffice to deliver to Mac users the features they wanted yesterday regardless of where those features came from. Sun has a history of a "not invented here" syndrome at times when it comes to code within their "open" source projects.
I'm glad to see that ooo-build is getting some recognition. I hope more users start seeing some of the great functionality they can get today on Windows and Linux, and once again I thank ooo-build, Ximian, and Novell for their continued dedication to improving OOo.
ed
Disclaimer: I am one of the founders of NeoOffice.
I think there's already interesting proof that forks can provide a very viable alternative to the overhead of the OOo project. Although the reasons are many, one of the big problems I historically had as a Mac OOo engineer was trying to get patches approved by Sun engineering. It has proven to be more efficient to have engineering freedom, allowing us to implement things that might never be approved by Hamburg. Being independent also has allowed us to implement a binary patching system so our bug fixes can be delivered quickly and independently if any marketing driven release schedules. Being outside the politics has also allowed us to integrate other open source technologies into the application that are important to Mac users, such as VBA support as well as OpenXML import and export. Yes, OpenXML import and export could be integrated into OOo today but engineering politics and Sun's manipulation of the project to foment a document format war have kept this functionality out of OOo, doing nothing except harm users that need to seamlessly integrate with MS Office environments.
NeoOffice has been shipping a solid, native, GPL licensed Mac product for over 2 whole years. We have shown forking is successful. Dropping the politics of the OOo organization has made us more efficient and resulted in a better product that users appreciate. We have had a free software solution for Mac for years, and all OOo has done is exorcise all reference to us from their website. Perhaps it is just banishment for daring to do things differently and not helping to propogate the name of OOo (which Jonathan Schwartz has publicly said is Sun's second most valuable brand after Java). Seems a bit like Sun wants control to me. It will be interesting to see if Sun has the stones to snub IBM for its Lotus Symphony brand in the same fashion.
ed
Disclaimer: I am a founder of the NeoOffice project.
The reason to include the source code is both moral and practical.
From a practical standpoint, it ensures that everyone providing NeoOffice needs to take no special action to comply with the GPL. According to our interpretation, anyone who provides a binary that is licensed under GPL is also obligated to provide the source code for that program. By placing the source code package within our disk images, anyone and everyone who provides the disk images is automatically providing source code. Everyone is fully compliant with even the strictist interpretation of the GPL without needing to do any extra work. This removes a lot of potential hassles and liability for our mirrors and other distributors.
From a moral standpoint, the origin of freedom within free software is the code. The GPL applies to the code, not the binaries; you can't license a binary under GPL without licensing the code. The source code is the freedom. It is worth a few extra bits to give everyone their freedom, even if they choose never to exercise it. Even if our servers go dark, everyone automatically has the source. Anyone can always exercise their rights, guaranteed. No one can ever take that freedom away from them besides themselves.
I think removing some of the pointless drivel on YouTube might be a better way to spare bandwidth and be "kinder to the Internet" rather than removing the guarantee of people's freedom. Perhaps I am just a purist.
ed
Disclaimer: I am a founder of the NeoOffice project.
Quote: and became an even worse idea when Apple deprecated the Java-Cocoa bridge
We never used the CocoaJava bridge at all. I guess you never bothered to read the source code. In fact, we use very little Java at all as is pointed out by the ohloh source code analysis of our open CVS. There's little Objective-C as we do most of the logic in C++ and call out to ObjC when required. There are some other stats there you may find intriguing as well like the estimated man-years and cost it will take to approximate our code.
Trust me, once any OS X port of OOo starts getting font handling and input methods correct, it'll slow down as well. This is true especially for Asian and other foreign languages. The bottleneck is in Apple's ATSUI and how it mismatches to the underlying OOo code. Has nothing to do with Java at all. Speed in a vaporware demo is one thing; carrying speed into a functional product is something different completely.
ed
Disclaimer: I am a founder of NeoOffice.org
Due to politics, OpenOffice.org has exorcised all reference that a perfectly functional, native, and Aqua port of OpenOffice.org exists for the Macintosh. It is called NeoOffice. If you want to use only software named "OpenOffice" on your Mac, yes, you have few options, but if you like GPL software go check out the real deal.
NeoOffice 2.1 is scheduled for release on March 27th. Not only do we continue to push forward with being the only truly native fully released Aqua-enabled office application suite for Mac OS X, there are several features included that aren't even in OOo on Linux, including:
NeoOffice is a GPL project and incorporates the best everyone has to offer to create the best product we can for our users.
OpenOffice.org is a political machine and to meet its own political goals is willing to restrict its users from compatibility requirements like OpenXML and VBA compatibility, not to mention failing to let users know other open source projects exist and are ready now, unlike their Macintosh vaporware. Their own users are hurt by their own desires for personal and political gain.
NeoOffice is free from all corporate influence, is truly GPL free software, and will always be so. If the lack of Mac support is your only reason preventing you from deploying OOo or its derivatives, it's sad that you didn't take the simple time to run a google search and just assumed the information the OOo website was all the larger OOo community has to offer.
ed
The article and the blog linked to it are somewhat trollish since Mac OS X hasn't really had an open kernel for some time. Still, this doesn't affect end useres in the slightest. With the public sources, all that could be built for PowerPC anyway was Darwin which is another BSD derivative. It's not OS X...it doesn't have Quartz, QuickTime, Java, Aqua, the Dock, Carbon, or anything else that makes OS X the operating system that it is. Those components of OS X were never open source and never will be. Where Darwin shined, however, was in opening up the source for drivers.
Some drivers can be made in user space, but a lot of drivers need to be coded in kernel space. When OS X first came out years and years ago, the procedures for writing drivers was horrid. Even today, it's still easy when writing drivers to make a coding error and get a kernel panic. Each kernel panic has a bunch of stuff in the log that allows developers to trace back the problem that caused the kernel to crash.
On PowerPC, the source code for the underlying drivers is available. This is invaluable since not only do you have the point in your code where you have a crash, but you can also figure out what IOKit or the kernel was trying to do that caused the crash. Being able to see exactly how the driver family is using your device is very helpful in figuring out either how to work around your bug or how you can remove it.
With the Intel OS X drivers, however, there is no source. You can't look back and see what the kernel is trying to do that caused your driver to soil itself. This makes debugging a pain in the neck since now, instead of being able to try and figure it out for yourself, you need to get Apple involved if you need more information. Having the PowerPC source isn't sufficient since the drivers are different between x86 and PowerPC. Case in point: right now I'm developing a USB audio device that works just fine on PowerPC but the moment you plug it into an Intel based Mac the OS kernel panics. I suspect a div by zero in the x86 driver, but I can't verify that since I can't see the source. Instead I have to rely on Apple to tell me what to fix.
Thankfully starting with Tiger a number of the more obscure kernel interfaces are actually a bit more abstracted for dlils and the like for which in the past reading kernel code and other drivers was almost the only documentation. That's still no reason for getting rid of the sources.
Although this lack of source is no new development, it really doesn't affect end users. The only people really building custom kernels for running OS X are the XPostFacto guys for running OS X on legacy hardware or PowerPC accelerators, and they never needed x86 code anyway. It affects hardware developers like myself and can make debugging a pain in the neck, especially if you don't have any of those paid-for ADC tech support incidents left.
ed
While Chapter 11 doesn't mean the company is dead (heck, airlines in chapter 11 are even merging these days) it would be very sad to see SGI go. One of the coolest things for me is the single system image computing, for example their Altix single system image supercomputers. High end scientific computing in the US has really thrown its weight behind clustering with off the shelf components (or, in IBM's case, custom components) working together over relatively slow interconnects. While this does work really well for types of problems that can be easily partitioned, not all problems can be easily dispersed. Additionally, many times researchers may not be the most proficient in MPI or other styles of programming that are really key to working well in a clustered system.
Single system image supercomputing offers a way to tackle some problems that can't be partitioned and also to make life easier for scientific programmers who are not well versed in distributed computing theory and practice. It would be a shame to see one of the last companies with that design philosophy disappear along with the technology and will to continue to implement supercomputer designs that don't follow the latest "fad".
ed
Disclaimer: I am an OpenOffice.org developer and a NeoOffice founder.
There are a number of tricks with which you may be able to improve presentation performance. First off, try 1.2 Beta. Older versions of NeoOffice/J were based on Java 1.3. Apple's virtual machine was buggy, so to implement drawing properly we needed to use triple buffering. With NeoOffice 1.2, we're using Java 1.4 and can access drawing buffers directly without working around bugs Apple never fixed in earlier VM versions.
Another thing to keep in mind is that you can always improve speed if you avoid transitions and animations in your presentation. Various funky cube wipes/dissolves add nothing to the content of presentations and just waste everyone's time and (I daresay) distract from the actual content. Folks should focus on what a bullet point actually *says*, not whether it flies in from the right, iris dissolves, or whatever. Sorry if it seems like a rant, but animations really are frills and should be used sparingly. In most every presentation using them, the "transition effects" actually detract from the content instead of providing meaningful information.
I've used NeoOffice and OOo X11 for presentations off of a 400MHz TiBook for years at O'Reilly conferences, business conferences, and others. If someone complains that their presentations run slowly, the first thing that runs through my mind is that it's not the type of presentation I want to be sitting through. Give me an overhead projector with transparancies anyday over something with sound effects and transitions that'll trigger seizures :D
ed
The problem is that those warnings are really runtime errors that will result in crashes in actual application usage. Unlike a lot of gcc warnings, they really can't be ignored and need to be fixed in order to get a running app :)
ed
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:
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
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
ed
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
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:
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 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
ed
These are the result of decisions made over a decade ago. OOo is now a 8 million line plus C++ application. It's very difficult, if not impossible to move to another language without a rewrite. Moving it to Java is a highly nontrivial task.
ed
The problem isn't the compiler, it's the build system. All the talk has been of how easy it is to use XCode and how Metrowerks folk (a non-trivial amount of devs) should move to XCode. XCode is not the answer, and for many Unix/Linux derived products may not even be feasible.
Support for delivery on two simultaneous architectures can get quite tricky for projects like OOo. OOo uses its own libraries in a "bootstrapping" process with a fair number of tools built from its own libraries that are used to perform resource compilation, custom makefile languages, check XML validity, etc. as part of the build. It is its own intricate build system that is difficult to replicate with tens of thousands of lines of makefiles. There's no thought given in this process to cross-compilation, and the build system is quite complex and will take some time to figure out.
This "miraculous" 2 hour port that Jobs has convinced all of the users will be possible just isn't. It's sad that the RDF is now being used to unduly pressure developers by stating "half-truths" about how easy this transition will be.
While I'm assuming that the fat binary format will *hopefully* be easy to figure out (like a Mactel subdirectory in the bundle), getting other build systems to build multiple architectures is not necessarily an easy task. If it's dependent on other XCode build procedure specifics it'll just be worse.
ed