[HOMBRESINIESTRO]

I just wanted to check whether the native OpenOffice.org port to OS X has accomplished anything in the last few months, when I stumbled across this posting by OPENSTEP about the problemhe has finding developers for OOo:

Yeah, these are all great suggestions. The websites, both OOo and Neo, do tend to be out of date and aren't 'flashy' in terms of end-users. I do have to agree with the vaporware criticisms, but then again, we just haven't had the kind of manpower to be able to push this thing forward

The project suffers from a very gnarly technical problem...we actually don't need "Mac" developers. "Mac" developers tend to want to do things the Apple way, either in pure Carbon with resource files or Cocoa with nibs and Objective C++. OpenOffice.org and Neo (by extension) are like the farthest thing from Mac programming. It thrusts programmers into a world where they need to know hardcore Unix programming, be comfortable with command line (e.g. non-Apple non-Metrowerks) build tools and debugging. It's not "Mac" programming, but more like programming for Unix geeks that switch over to Mac.

Don't get me wrong, the KOffice guys are great and all, but they're Qt programmers...they're not "Mac" programmers. OOo is at a disadvantage as we need to port the underlying widget set, whereas KOffice has the benefit of having a fully-funded company (Trolltech) doing their widget port for them (Qt). Qt was ported to the mac by trolltech, and KOffice is just a side-effect.

In some respects, it's a tradeoff...Sun is pushing StarOffice and OOo to be more competitive from a feature standpoint. KOffice isn't nearly as functional yet, but definitely has been pushed to be more cross platform then OOo.

It still doesn't help answer the question of how to find more "Unix" developers on OS X to push progress along. We haven't done screenshots and progress updates since, well, there's not been much to report. Even if we have a wonderful professional style of presentation, it won't change the fact that we still only have two part time core developers who are limited to putting in only as much time as they can.

I admit, personally there was a time when I thought I could change the world through OOo. I was unable to find the help I needed to get it done :-( Really, even to do continual maintenance of OOo X11 is nearly a full time job. It's hard to find people to be that dedicated to volunteer in the lnog term. That's what I'm up against. After all of the time and money I put into doing so, we really only found one person...Dan. Only a couple of people are just not enough to get this done.

This project needs specialized skills, a lot of development time, and a long-term committment. Unfortunately, those are three things that are hard to come by from volunteers.

Everyone wants to use it, but no one seems to be willing to step up the plate and help develop it. FOSS software doesn't come for free...people do make sacrifices of time and personal lives to write it. Unfortunately, there's only so much one can give up for something that has no reward.

This is a project everyone wants to use, everyone wants to succeed, and with two years of experience searching for help, apparently no one wants to volunteer to help develop after getting to know the code. Without more development volunteers, the project will just get done when it gets done. I wish I had insight as how to get them. Between that "volunteer" requirement and the Sun JCA requirement most developers seem to be utterly turned off. Using GPL hasn't helped either. I guess the code is just too ugly for sane people to want to touch with a 10 foot pole. :-(

I feel very sad that the Mac community was and apparently _is_ not able to support such a wonderful and very promising project. :-(

OOo is a great app with all the features of MS Office that could have been available as a native app - even with an aqua look - if it would have had some more developers. That way it really would have been a competitor for Office.

But it did not happen because.... I really don't have an answer why. Perhaps it's one paragraph out of OPENSTEP's text:

Everyone wants to use it, but no one seems to be willing to step up the plate and help develop it. FOSS software doesn't come for free...people do make sacrifices of time and personal lives to write it. Unfortunately, there's only so much one can give up for something that has no reward.

For Linux und Windows (and even Solaris), OOo has corporate backing. I read somewhere on the OOo homepage that the Sun developers do the big part of the work.

Is this a clue that big OSS projects cannot survive when they are developed in private only?

I don't know but I feel very desperate and sad and just wanted to share my thoughts with you.

[Keiretsu]

Did you think about one reason why nobody wants to work on OO:
- it's not written in Cocoa but in C/C++ which is definitive less fun
- MS Office runs just fine on Mac OS X

Mac OS X does not have the same problem as Linux: the usual stuff is there (Adobe, Macromedia, Microsoft etc.), so there is less need. If you are orthodox non-MS you'd need OO else you just buy a copy of MS Office whenever someone runs a special ... and BTW all Edu people get it really cheap and these folks make up a lot of the OpenSource programming power.

My 2 cents ...

[hyperb0le]

Originally posted by Keiretsu:
Did you think about one reason why nobody wants to work on OO:
- it's not written in Cocoa but in C/C++ which is definitive less fun
- MS Office runs just fine on Mac OS X

Mac OS X does not have the same problem as Linux: the usual stuff is there (Adobe, Macromedia, Microsoft etc.), so there is less need. If you are orthodox non-MS you'd need OO else you just buy a copy of MS Office whenever someone runs a special ... and BTW all Edu people get it really cheap and these folks make up a lot of the OpenSource programming power.

My 2 cents ...

OpenOffice.org is great, but there really isn't much of an incentive for people to develop the OS X version. If it was being rewritten for Cocoa, I know a ton of devs, including myself, would jump on it. But there are very few devs who want to abandon Apple's dev tools to pursue OpenOffice.org

[Cadaver]

I've played with OOo on Mandrake Linux and Windows... I find nothing about it that makes me wish we had a completely OS X native version. Its just a direct copy of MS Office (circa 1997) for Windows - lousy icons, poor Microsoft UI and all. All the crap that makes me not want to use MS Office in the first place.

I do have a copy of Office 2004 for MacOS X ($12 University faculty price of course), and I use it when necessary (particularly PowerPoint), but prefer to use something else for word processing whenever possible. Mellel's not bad at all (it has a few interface quirks that I'm getting used to). Waiting patiently (and hoping its good) for Nisus Writer Express 2.0.

Most Windows users don't even realize I'm sending them .rtf files instead of .doc files.

There are still times when I must use Word, though... Some documents, no matter what I do, always tend to format just slightly differently - but different enough - in Word compared to other applications. I think its Word that's 'wrong', but unfortunately its what I must conform to.

But for the most part, I send out either .rtf files, or .pdf files when formatting must be 100% identical.

[HOMBRESINIESTRO]

Originally posted by Cadaver:
I've played with OOo on Mandrake Linux and Windows... I find nothing about it that makes me wish we had a completely OS X native version. Its just a direct copy of MS Office (circa 1997) for Windows - lousy icons, poor Microsoft UI and all.

I must admit it looks very much like Windows, but the uderlying word processor and spreadsheed app is great. Espacially formatting is much more logical than it is in Word. The stylist is great, too. Moreover it produces a layout that is much more stable than Word when working on large documents (>30 pages) with graphics and text.

For the real native Mac port the UI would change of course so that OOo would respect the HIG. If you want a native version of the windows style UI, take NeoOffice/J. I mean, this one's already there. What I really miss is a real competitor to MS Office.

As for the coding process. Wouldn't it be possible to rebuild the UI in Interface Builder and than bridge to the uderlying code in the OOo core?

I know this would be the most difficult way to do this and I'm no developper myself, but that way you could use XCode _and_ port OOo to OS X.

I hear many people telling me that Word is allright and OOo looks like and is crap. Of course this depends on the subjective point of view, _but_ it _is_ better to have competition everywhere. Even on the word processor market. Mellel, NisusWriter, TextEdit etc. are _no_ competitors for MS Office, but OOo is!

[yukon]

It's a criticism I've made before, FOSS programmers shouldn't copy Microsoft. Sure, it wins a few converts, but it's just working on a direction that doesn't necessarily improve anything. It's good to keep pairity with the good features, and it's nice when there's a windows "skin" or look (IceWM is particularly comforting to a new user), but copying behaviors simply because MS uses them, that's not where anyone wants to go.

Anyway, I'm not quite certain about this whole "port it without rewrites" thing, it obviously isn't working, and apparently few people even know how to do it, while there are "a ton of devs" who would help with a cocoa port. I don't know the specifics, but the Windows port isn't X11, it has to use Win32 APIs, and it seems very fast and it's polished enough to look "native" to windows (gotta love the installer) - if there are developers willing, why can't this happen on OS X when it actually does have a UNIX environment available? ISTR running Mozilla in OS X Beta.

I'd like to see a good port. I don't have Office, I don't want Office, but using the latest Appleworks is pretty bad, it crashes so I just do the formatting in it. Apple could encourage OO somehow. Maybe (secret redmond handshakes permitting). Rebrand it as AppleOffice (if the licences allow), start off with Cocoa and make it kick ass.

[HOMBRESINIESTRO]

Originally posted by yukon:
Anyway, I'm not quite certain about this whole "port it without rewrites" thing, it obviously isn't working, and apparently few people even know how to do it, while there are "a ton of devs" who would help with a cocoa port. I don't know the specifics, but the Windows port isn't X11, it has to use Win32 APIs, and it seems very fast and it's polished enough to look "native" to windows (gotta love the installer) - if there are developers willing, why can't this happen on OS X when it actually does have a UNIX environment available?

I don't know either why this isn't possible for Mac OS X. As I stated above, this would also allow to work with XCode. I would love to see this happen, too (see my last posting)!

I'd like to see a good port. [...] Rebrand it as AppleOffice (if the licences allow), start off with Cocoa and make it kick ass.

Apple has missed a chance here. But I think it would be a good thing for the Mac community if this would be possible without the mother ship! Here's another problen in the scenario: Mac users expect Apple to solve their problems. But Apple int his case doesn't want or can't kick MS's ass.
I think this is also the fact that makes me feel so sad about it. Obviously it's not only a problem with the developer tools to work on OOo, but also the lacking support of the end users due to their strong believe in Apple. That's why I say: The Mac community has failed on this one!

[JKT]

I think there is one aspect of this that you are neglecting and that is the lack of (official) support from Sun themselves - I don't see a MacOS X version of StarOffice, do you? If Sun had backed the development of a version of StarOffice for OS X, do you think we would be in this current situation vis a vis OpenOffice.org (OOo is the open source base for StarOffice for those that didn't know)? Apple and Mac users/developers aren't entirely to blame.

The great shame of all this is that, without a Mac native version of OOo (NeoOffice/J notwithstanding), when all these governmental organisations (such as Munich) etc consider the switch to non-MS solutions, the Mac is unlikely to be considered because of it.

[wataru]

This news would be very disappointing to me if I hadn't already moved to LaTeX for my word processing needs. Oh well.

[hudson1]

I find the Mac version of MS Office to be far more polished and "Mac-like" than any of the open source word processors like OOo, Abiword, and NeoOffice/J.

And since Mac users, in general, flock to software that's polished and Mac-like, it's no wonder that the open source word processors haven't caught on all that well in the Mac community.

On Windows systems, users are less used to good looking interfaces and so the concept of "free" becomes the overiding criteria. In the Unix world, any interface at all is a step up.

[HOMBRESINIESTRO]

Originally posted by hudson1:
And since Mac users, in general, flock to software that's polished and Mac-like, it's no wonder that the open source word processors haven't caught on all that well in the Mac community.

This is what this thread is all about. Noone would prefer the windows-style OOo over MS Office. But it would be possible to rewrite the interface of OOo using the Cocoa libraries and giving it an even better interface than MS Office.

It's not about how it is adopted now, but that the users say: "Hey, I have a nice looking Office: MS Office, and I don't need any competitor for it." That's how you reacted too, but this is a bit narrow minded. If the Mac community would see the potentials of an aquafied OOo, and support it with development efforts and strong user _support_, we could have a better Office package, with a better interface at no cost.

[TETENAL]

Originally posted by HOMBRESINIESTRO:
[ I]t would be possible to rewrite the interface of OOo using the Cocoa libraries [...]

I think the OOo code makes assumptions (like it can draw its own widgets) that make this not possible.

If the Mac community would see the potentials of an aquafied OOo, and support it with development efforts and strong user _support_, we could have a better Office package, with a better interface at no cost.

And that's why we won't have it. Nobody is going to work for years for free or the prospect of a thank you e-mail.

[thePurpleGiant]

Originally posted by HOMBRESINIESTRO:
It's not about how it is adopted now, but that the users say: "Hey, I have a nice looking Office: MS Office, and I don't need any competitor for it." That's how you reacted too, but this is a bit narrow minded. If the Mac community would see the potentials of an aquafied OOo, and support it with development efforts and strong user _support_, we could have a better Office package, with a better interface at no cost.

Problem is this: I would love to see a 'good' OpenOffice for the Mac. I like competition, and I would like to have an alternative there that is cheaper, and doesn't depend on Microsoft's continued support. In that sense I would like to support the project.

However, I have MS Office. I use it, and I like it. I use it for work very frequently, and find it a very competent program. I have tried OpenOffice and found it hampered my productivity quite a bit. How should I support this program, when it doesn't fulfill my needs? I can't program, so I can't help out with development. And I hardly feel like 'testing' OpenOffice for the good of the platform, and then also having to use MS Word for my work.

So what is the solution? It seems to me this is one of the critical problems with OpenSource software for larger projects. It's not that I wouldn't like OpenOffice available natively for Mac, but how should I support this development, when I don't actually require it?

[Graymalkin]

While it would be nice to have a Free native alternative to Office v.X/2004 we're not going to see it for a while. The Qt port of OpenOffice was stalled for the same reason the OSX port has been largely stalled. The current graphical toolkit (VCL) that OO.o uses is going to be replaced in the 2.0 codebase. There's little point right this second porting the existing GUI to any native graphical systems, Aqua included. The current MacOS efforts on OO.o involve merging the patches into the main code trunk and removing the X11 dependancies. Once a non-X11 port is available that is pretty much all that will exist on OSX until the 2.0 codebase is finalized.

There's a lot of work right now on getting OpenOffice to be more portable and act as a native application on various host platforms. This is important not only for an OSX port but also Windows and Linux ports. OpenOffice is a bit of a PITA running alongside native apps on any platform because it only marginally resembles a native application. Its behavior and widgets don't necessarily conform to the rest of the system. Right now there's a number of OO.o projects that are dependent on a toolkit migration, again Aqua included.

OpenOffice is ~7.5 million lines of code and uses toolkits that only a handful of people have experience with. I'm not surprised in the slightest the porting efforts have had so much trouble and so few developers. There's not too many folks with hefty Unix and Mac programming experience that are willing to donate an untold number of hours to working on OO.o. Unfortunately a good deal of OO.o's functionality is tied directly to individual components which are in turned tied heavily to their graphical frontends. Unfortunately it isn't like you can just wrap libooo.dylib up in a nice NIB-based GUI and have an instant Cocoa application.

[HOMBRESINIESTRO]

I just want to add this article from /.

http://slashdot.org/articles/04/08/2...=1&tid=218

Of course XML is there on the Mac, too, and is perhaps what Apple is going to push at last. But the alternative called OOo is unfortunately not available.

[solbo]

Originally posted by Graymalkin:
Unfortunately it isn't like you can just wrap libooo.dylib up in a nice NIB-based GUI and have an instant Cocoa application.

That is too bad. I wonder why people don't think about this kind of thing when they start building this stuff? Did Sun just not think that it would be important in the future to have an easily portable product?

[HOMBRESINIESTRO]

Originally posted by solbo:
That is too bad. I wonder why people don't think about this kind of thing when they start building this stuff? Did Sun just not think that it would be important in the future to have an easily portable product?

Fact is that Sun did not develop OOo. OOo is the open source version of StarOffice (which _was_ available for the Mac, too btw).
Sun bought the StarDivision, a German company that developed StarOffice in 2001 (correct me if I'm wrong) and then released the StarOffice code as open source and called it OpenOffice.org. Since then OOo has evolved very much and the developers try to make it more versatile, but from what I've heard it is a mess of code.

[milhous]

I'd like to see something happen with WordPerfect, though I don't think Corel is going anywhere these days.

[wataru]

I don't know if anyone cares, but NeoOffice/J 1.1, which will be based on OO.o 1.1, will be out in alpha in early September. I'm looking forward to it.

[HOMBRESINIESTRO]

Originally posted by wataru:
I don't know if anyone cares, but NeoOffice/J 1.1, which will be based on OO.o 1.1, will be out in alpha in early September. I'm looking forward to it.

This sounds very promising, although I would prefer them to work on the OOo 2 branch, so that we could have a NeoOffice/J 2 nearly at the same time as it comes for the other platforms.

[wataru]

Originally posted by HOMBRESINIESTRO:
This sounds very promising, although I would prefer them to work on the OOo 2 branch, so that we could have a NeoOffice/J 2 nearly at the same time as it comes for the other platforms.

I don't know the details, but I think that idea was discarded as unrealistic for a couple reasons. One is that it's much harder to write a Java shell around a moving target. Another is that 1.1 is significantly improved but not quite so different internally from 1.0, so the move would not be as difficult.

There's only one developer working on Neo/J. He's doing a great job, but you have to recognize the limitations of a one-man team.

[HOMBRESINIESTRO]

Originally posted by wataru:
There's only one developer working on Neo/J. He's doing a great job, but you have to recognize the limitations of a one-man team.

I do! And I really appreciate his work. My comment was never ment to critizise his efforts!

[wataru]

Originally posted by HOMBRESINIESTRO:
I do! And I really appreciate his work. My comment was never ment to critizise his efforts!

I know. It was more of a general comment. It's too bad more people can't get involved. I'd love to help, but I'm no programmer.

[Sven G]

Couldn't it be possible, as a very first step, to at least skin OpenOffice.org, in order to have more Aqua-like icons?

For example, AFAIK, there's a project for OOo KDE integration, also with some better icons: a similar thing could maybe be done also with OS X/Aqua (waiting for more substantial integration, of course)...

P.S.: If I'm not mistaken, SuSE Linux has the skinned OOo right out of the box.

[lngtones]

Originally posted by HOMBRESINIESTRO:
The project suffers from a very gnarly technical problem...we actually don't need "Mac" developers. "Mac" developers tend to want to do things the Apple way, either in pure Carbon with resource files or Cocoa with nibs and Objective C++. OpenOffice.org and Neo (by extension) are like the farthest thing from Mac programming. It thrusts programmers into a world where they need to know hardcore Unix programming, be comfortable with command line (e.g. non-Apple non-Metrowerks) build tools and debugging. It's not "Mac" programming, but more like programming for Unix geeks that switch over to Mac.

It's sure easy to get support for your project when you flat out say you don't care about what the people who want to work on your project want. I don't understand the purpose of using a Mac if you don't want "Mac" applications. This is exactly the reason I don't understand why people toot the OpenOffice.org horn so much. It's a "geek" monstrosity. They take pride in the fact that it's ugly, bloated, complex, and hard to work on. Who wants to deal with people like that?

[yukon]

Sounds like a good idea....better, but then you end up with an application that looks weird and acts weird, that just uses graphics taken from OS X to display rather than using OS X to display things. I haven't seen it skinned before, but surely there are just little images that could be changed and some background colors. Anyone see that in the source somewhere?

I bet the code for an office suite is pretty damn hard to make modular....would be nice if there could be a libopenoffice for frontends to use

[wataru]

Originally posted by lngtones:
It's sure easy to get support for your project when you flat out say you don't care about what the people who want to work on your project want. I don't understand the purpose of using a Mac if you don't want "Mac" applications. This is exactly the reason I don't understand why people toot the OpenOffice.org horn so much. It's a "geek" monstrosity. They take pride in the fact that it's ugly, bloated, complex, and hard to work on. Who wants to deal with people like that?

I think that's more than a little bit too harsh of you. From their perspective, it's more like these fringe Mac developers, who are few in number and don't seem too interested to begin with, say that they won't touch the project without tearing it apart from the bottom up. I think part of the problem is a lack of demand, too: Mac users are, by and large, happy with MS Office, so why should they bend over backwards for us?

No one takes pride in ugly, bloated, and complex code. That's why they're redoing so much of it for 2.0. But to criticize them for not spending 100% of their resources on spitting out a "pretty" Mac version immediately is just stupid. They have bigger fish to fry.

I believe 2.0 will bring us much, much closer to a pretty Mac version.

[Graymalkin]

Office suites were the sort of applications component-based programming paradigms really stemmed from. Each aspect of a productivity suite lends itself well to a component architecture as the individual components can simply be stuck into an application wrapper or inside of individual documents. OpenDoc was an implementation of this paradigm. While components are nice inside the realm the original author designed them for they tend to break when used in ways the author didn't envision.

[lngtones]

Originally posted by wataru:
I think that's more than a little bit too harsh of you. From their perspective, it's more like these fringe Mac developers, who are few in number and don't seem too interested to begin with, say that they won't touch the project without tearing it apart from the bottom up. I think part of the problem is a lack of demand, too: Mac users are, by and large, happy with MS Office, so why should they bend over backwards for us?

No one takes pride in ugly, bloated, and complex code. That's why they're redoing so much of it for 2.0. But to criticize them for not spending 100% of their resources on spitting out a "pretty" Mac version immediately is just stupid. They have bigger fish to fry.

I believe 2.0 will bring us much, much closer to a pretty Mac version.

Who said 100%? This email or wherever it came from is saying not at all. What I'm saying is there are Mac developers that want to work on the project and see what they can do but they're being told not to because they aren't "Unix geeks." Which isn't even that true. I know many "Unix geeks" who have switched to OS X and appreciate how OS X programs work. Anyway, the point is it wouldn't hurt anything to have new developers working on a Mac version but I guess that's seen as "uncool" by this guy. Creating a Mac like open office wouldn't require taking it apart from the bottom up and it wouldn't affect any other OS.

[Graymalkin]

Originally posted by lngtones:
Creating a Mac like open office wouldn't require taking it apart from the bottom up and it wouldn't affect any other OS.

Yes it would. The graphical portions of OpenOffice's components are heavily tied into X11 display calls. A group of KDE developers tried porting OpenOffice's components from VCL/X11 to Qt in an effort to make the widgets and events all Qt-native and thus fully compatible with Qt-based environments. They've pretty much given up their porting effort until the OpenOffice 2.0 codebase matures. The KDE folks have run into the same issues as the people working on the Mac port, there's a lot of X11 dependance in OpenOffice.

It isn't possible to just build a NIB-based GUI on Xcode and writer a controller for libopenoffice because there is no libopenoffice. The functionality of OpenOffice is entirely tied to components that marry display logic to application logic. There's no single group of traditional libraries that developers can implement to replicate the features of those components.

[lngtones]

Originally posted by Graymalkin:
Yes it would. The graphical portions of OpenOffice's components are heavily tied into X11 display calls. A group of KDE developers tried porting OpenOffice's components from VCL/X11 to Qt in an effort to make the widgets and events all Qt-native and thus fully compatible with Qt-based environments. They've pretty much given up their porting effort until the OpenOffice 2.0 codebase matures. The KDE folks have run into the same issues as the people working on the Mac port, there's a lot of X11 dependance in OpenOffice.

It isn't possible to just build a NIB-based GUI on Xcode and writer a controller for libopenoffice because there is no libopenoffice. The functionality of OpenOffice is entirely tied to components that marry display logic to application logic. There's no single group of traditional libraries that developers can implement to replicate the features of those components.

Ok, so I reassert: ugly, complex, and bloated. Separating the widgets from the application logic has been a strong OOP design pattern since the very beginning. I'm not sure when the GOF book came out but that's one of the first things they discuss. Who's bright idea was it to mix everything together.

[yukon]

Sometimes it's a good idea to tear everything down and rebuild. OSS is awesome because the products are usually easily portable (or more often ported by someone else already). It sounds to me that OO is bloaty, monolithic, and tied to it's original platform....but then, it runs on Windows without cygwin...

[Graymalkin]

Originally posted by yukon:
Sometimes it's a good idea to tear everything down and rebuild. OSS is awesome because the products are usually easily portable (or more often ported by someone else already). It sounds to me that OO is bloaty, monolithic, and tied to it's original platform....but then, it runs on Windows without cygwin...

StarOffice also used to run on OS/2 back in the day. The Windows and OS/2 ports of StarOffice were just lightly wrapped on top of the native GUIs. None of the widgets were system native, neither were any of the GUI events. Like the current versions of SO/OO they were all run internally.

Originally posted by lngtones:
Ok, so I reassert: ugly, complex, and bloated. Separating the widgets from the application logic has been a strong OOP design pattern since the very beginning. I'm not sure when the GOF book came out but that's one of the first things they discuss. Who's bright idea was it to mix everything together.

The issue isn't OOP, OpenOffice is designed thuroughly with OOP principals. A component doesn't directly code any GUI aspects necessarily, it just tells OpenOffice what sort of GUI elements to display and what they do and where to put them. While this follows object oriented paradigms it means those components are hard to use for anything but what they were specifically designed for. Components just typically aren't designed to be as broadly usable as class libraries and frameworks. If you just want to use a single method from java.math you can just import the methd and you're off. All you have to do is give it the right input and accept the correct output. A text-search-and-replace-with-a-window component isn't are broadly useful if all I want to do is perform a search of some text. OpenOffice is laden to the hilt with OOP, it is just usng an old, overengineered, and largely out of date OOP methodology; in my humble opinion.

[Sven G]

BTW, a screenshot of the SuSE version of OpenOffice.org: we'll probably have to wait a long time before something similar comes to OS X, anyway...

[yukon]

I've been told that there's "...talk of reimplementing it (OO) from scratch in GTK2". But what large open source project is complete without it's own widget set? Might as well move to GIMP's ;-)

[lngtones]

Originally posted by Graymalkin:
The issue isn't OOP, OpenOffice is designed thuroughly with OOP principals. A component doesn't directly code any GUI aspects necessarily, it just tells OpenOffice what sort of GUI elements to display and what they do and where to put them. While this follows object oriented paradigms it means those components are hard to use for anything but what they were specifically designed for. Components just typically aren't designed to be as broadly usable as class libraries and frameworks. If you just want to use a single method from java.math you can just import the methd and you're off. All you have to do is give it the right input and accept the correct output. A text-search-and-replace-with-a-window component isn't are broadly useful if all I want to do is perform a search of some text. OpenOffice is laden to the hilt with OOP, it is just usng an old, overengineered, and largely out of date OOP methodology; in my humble opinion.

Then how can it be dependent on X11. If it was designed correctly, it should be possible to code the widgets using platform specific calls and change the factory method that creates the widgets to use that platform's widgets.

This obviously wouldn't solve every problem, but I don't understand how it can be dependent on X11 if it was designed properly.

[Graymalkin]

All drawing in OpenOffice is offloaded onto a framework called Graphic System Layer (GSL). A large part of the GSL is the Visual Class Library (VCL). VCL is what handles all of the widgets in OpenOffice and allows for hooks to native system calls for tasks such as printing or font discovery. VCL also supports plugins on Unix systems to map VCL's widgets to native looking widgets for different toolkits (Xlib, Motif, GTK+, etc.).

So you'd think it would be fairly simple just to write an Aqua plug-in for VCL and be done with it. If only it were that easy. VCL uses a framework called System Abstraction Layer (Sal) that provides a generic interface for all drawing tasks. If you want to make a plugin that makes OpenOffice act fully native you have to implement every Sal interface yourself. This part is where X11 is painfully tied into OpenOffice. It is very difficult to write a plugin that fully implements the entire Sal interface and have it work well. The generic interface just uses X11 events and basic Xlib drawing commands. A native Aqua build of OpenOffice would require a plugin written to fully implement Sal interfaces and map them to Quartz events and drawing commands and Aqua widgets.

So now you've got to put a ton of work into building an Aqua plugin and even then OpenOffice won't act like a real Mac app because it won't be using Mac keyboard shortcuts and VCL's main application menu won't be mapped to the Menubar. On top of all that VCL as a toolkit is being dropped in the OO.o 2.0 codebase. They're moving to a far less complex drawing system and relying on fewer abstractions to make it easier for OpenOffice to take advantage of native widgets and events and the like.

All of the drawing problems are entirely separate from the component architecture. I brought up OO.o's component model as a means to explain why it wasn't possible to just build a native Cocoa interface on top of OpenOffice's components. I wasn't trying to equate components and GUI marryings with the problems writing an Aqua plugin. I appologize for the confusion.

I hope it is apparent now that OpenOffice's design is bloated and overly complex. The reason "Mac programmers" and Metrowerks adherents aren't "welcome" is because the development of OpenOffice is so ridiculously unlike traditional Mac development. People used to developing with Cocoa or PowerPlant will have a hard time going through OpenOffice code. Some Unix programmers that have been working with CORBA systems like Bonobo will find themselves more at home.

[sdf]

Originally posted by lngtones:
It's sure easy to get support for your project when you flat out say you don't care about what the people who want to work on your project want. I don't understand the purpose of using a Mac if you don't want "Mac" applications. This is exactly the reason I don't understand why people toot the OpenOffice.org horn so much. It's a "geek" monstrosity. They take pride in the fact that it's ugly, bloated, complex, and hard to work on. Who wants to deal with people like that?

My thoughts exactly. It seems like NeoOffice is the only way we'll ever see traction on Open Office... someone willing to throw away everything but the source code he wants.

[passmaster16]

Originally posted by milhous:
I'd like to see something happen with WordPerfect, though I don't think Corel is going anywhere these days.

True, I thought Corel would have been better off retaining WordPerfect on OS X than Windows. I think they would have had more of a market. The fight on the Windows side has been lost to MS Office and if people wanted an alternative, they could go to OOo rather than WP. On the Mac side, while many use Office, they would have a nice market for a competitor.

Regardless it's a shame that OOo will probably not make it native to X in a long time if ever. I use MS Office. It's ok. It doesn't run as fast as it does on Windows for obvious reasons. I always like more competition even if I don't intend to use the product.

[passmaster16]

Originally posted by wataru:
I don't know if anyone cares, but NeoOffice/J 1.1, which will be based on OO.o 1.1, will be out in alpha in early September. I'm looking forward to it.

Looks like it was just released? http://trinity.neooffice.org/

[The DJ]

I'll have too chime in here a bit.
I very much feel for OPENSTEP. I know personally how hard it is to work in such an environment. With VLC media player we sorta have the same thing, but luckily the project is smaller, and support has been strong, because from our early days we were one of the few players easily displaying MPEG2 and later diVX on MacOS X.
This kinda carried us beyond the vaporware stage. We have 2 OS X developers that spend a huge amount of time on it in their free time.
And still even WE see exactly the same problems that he is describing.

I know of only a single project that has been truly effective in this kind of design and that is mozilla. In essence OO.o can be considered the Mozilla of Office applications.
And we all know how succesfull they have become.

So I would like to see the Mac community give it all a bit more time and support. Look at the wonders of mozilla and hope that with your support, OO.o will come out better than anything ever before..

[TETENAL]

The difference is that the Mac version of Mozilla was financed by Netscape/AOL and done by professional programmers.

[solbo]

Camino is great, it uses Gecko as a back-end which was seemingly fairly easy to accomplish due to Gecko's, by design, cross platform nature.

Firefox, Thunderbird, and the Suite also run fairly well in OS X, although they are using XUL and basically their own toolkit for rendering. Although the Mac versions have come a long way due to some creative theming, they still don't feel like true native apps. But it is amazing what skinning can do to make the experience so much better.

Mozilla has a significant advantage over OO.o in that it was built from the start to run on practically anything. OO.o has a long way to go to get that level of portability. From the sound of how things are, it would almost be better for them to gut it and start semi-fresh with a clearer more well defined goal.

[the_glassman]

While OpenOffice and NeoOffice aren't pretty they are making steps in the right direction.

[discotronic]

Originally posted by Sven G:
BTW, a screenshot of the SuSE version of OpenOffice.org: we'll probably have to wait a long time before something similar comes to OS X, anyway...

I've been messing around with SuSe 9.1 since May. The first time I fired OOo up I was very impressed with the overall look. It is nicer than the Windows port. I would use it if the Mac port looked as good.

For me, using OOo or NeoOffice in it's present state wouldn't be a big deal. My better half on the other hand doesn't understand how to do something as simple as saving a file with the way it is set up now.

[JKT]

With the move to the 1.1.x codebase, you can now apply different icons at least.

[leperkuhn]

Originally posted by hyperb0le:


OpenOffice.org is great, but there really isn't much of an incentive for people to develop the OS X version. If it was being rewritten for Cocoa, I know a ton of devs, including myself, would jump on it. But there are very few devs who want to abandon Apple's dev tools to pursue OpenOffice.org

I haven't looked at any of the code, so I can't be sure about this but...

was it written like Gaim, with libraries that do most of the work (OOP), or was it written like a huge mess of code?

Libraries would mean someone could develop a native version, with a cocoa interface.

[[APi]TheMan]

I wasn't sure by the looks of where this thread left off if it was clear that NeoOffice/J has been updated too... It now uses the OOo 1.1a2 backend whereas the previous version was stuck at .8.2. It's a very nice application now and I'm pretty sure I'll never fire up X11 for OOo again.

Check it out at the NeoOffice/J site: http://www.planamesa.com/neojava/en/index.php

[wataru]

Uh, that's pretty old news at this point.

The real news is that there is a patch that gives NeoOffice/J real Aqua menus instead of the menu-in-window thing.

[Krypton]

Open Office 2.0 is nearing completion, which was supposedly going to be the basis for a native Mac OS X port yes?