Slashdot Mirror
Aqua OpenOffice.org v2.0 Cancelled
Ant writes "According to MacSlash's story, a recent post on OpenOffice.org said no Mac OS X work has been done since 2003 and that there are no longer any plans for an Aqua version 'due to various licensing, political, and fundamental engineering difficulties'. :("
Open Source fail it? That's unpossible?!
If you find this post offensive, don't read it! THINK ABOUT YOUR BREATHING! I am what I am because of how apes behave.
Forgive my ignorance, but doesn't OS X include an X11 server? Is there any major drawback to running OpenOffice as an X11 application rather than a native one?
FTA as a reason not to do Quartz or Aqua "X11 Will Always Look like Other Platforms: Many people deploying OpenOffice.org count the identical look and feel on all supported platforms as a major benefit. It helps them reduce training and, in many cases, implement a single multi-platform solution using OpenOffice.org as middleware (such as extendedPDF). Any native work that changes the interface would remove this as a critical selling point for OpenOffice.org for these users."
;)
Umm, I have yet to hear one negative comment regarding Aqua interfaces (done right). This comment appears to be nothing but pure FUD. If anything, an Aqua UI would make an OOo suite EASIER to use on an OS X system.
But, again, whatever. I can't wait to get ahold of Pages. Apple seems to have finally woken up and realized they need their own (updated) office/productivity suite. OOo is great and all, but if their team seems to have the attitude "one platform, one UI" is better, I'll pass.
Besides, there's always NeoOffice/J to root for!
It's disappointing news, but at least there's still the NeoOffice project. Its was originally intended to be a place for experimenting with the issues involved in a native OS X port, but if the office OOo project won't be doing it hopefully NeoOffice will get more support as the primary (er, only) Aqua version.
Except for that in the first paragraph of the article it says that a port is being released by NeoOffice. Did anyone even rtfa?
With Apple now getting into the office suite arena, I'm far more inclined to buy it then get the free Open Office anyways.
Yes, I'm willing to pay for superior alternatives.
It's possible to compile OpenOffice using Qt for the interface (e.g. in OpenOffice/KDE). Since Qt is available with an Aqua frontend, why not use that?
It wouldn't provide overly tight integration with the MacOS X user interface, but it would be way better than today's X11-based OpenOffice.
As a state gets corrupt, its laws multiply; the most corrupt states have the most numerous laws. (Tacitus, Annales 3:27)
The story isn't very informative, but since the Neooffice people seem to have a good port underway for OS/X, there isn't a lot of reason to go after pure aqua anyway. If this brings more resources to the Neooffice folks, then I don't see this as a bad thing at all.
Just a happy Neo Office user who loaded in a bunch of Excel sheets annd got a lot of work done.
Other than being free, I don't see what OpenOffice has to offer on the OS X platform. KeyNote works great, version 2.0 looks even better, and for those who care (and I'm one of them), the file format is xml-based and completely transparent. The OS X paradigm of encapsulating applications and documents in a directory instead of some gigantic kludgy single file means you can go into a .key file and see all the images and movies you've added to the presentation, as well as a single "presentation.apxl" file that contains the presentation itself in a completely obvious xml format.
.edu discount.
The new word processing program for the Mac announced at this year's MacWorld, called Pages, was written by the same team that wrote KeyNote and presumably uses the same open file formats.
And these programs together are $79; even less if you can get the
There's no Apple spreadsheet program (yet)...
This makes AbiWord's introduction of a Cocoa port even more newsworthy, in my opinion. Yes, I know it's not as robust an offering (I'm not sure how it could be with drastically different methods of development), but being able to read documents across the three major platforms in the same native format is a huge plus for me. YMMV, though.
Ant writes "According to MacSlash's story, a recent post on OpenOffice.org said no MacOS X work has been done since 2003 and that there are no longer any plans for an Aqua version 'due to various licensing, political, and fundamental engineering difficulties'. :("
It says nothing of the kind. From the link:
Due to various licensing, political, and fundamental engineering difficulties it is likely, for the near future, that native Aqua porting work will be based off of the NeoOffice.org project and not under the direct aegis of OpenOffice.org.
and
For the last year and a half all engineering work focusing on a native Mac OS X OpenOffice.org version has been concentrated in the NeoOffice/J project, using a combination of Java and Carbon technologies to replace X11.
What it looks like is that they have recognised that NEOoffice is a valid port, and any Aqua port by themselves would be a duplication of effort. The Slashdot story blurb makes it sound like they just gave up because it was too hard. They call this journalism now?
First of all, this is NOT related to Apple announcing iWork. At all. No, there's no conspiracy.
Second, this is OLD news. Anyone who's even remotely followed OpenOffice.org Mac OS X porting work knew any potential Aqua port was on the back burner. Way on the back burner. With the stove unplugged.
Third, the X11 port will ALWAYS continue to exist.
Fourth, there is a Mac OS X graphical port, albeit via Java, in the form of NeoOffice (1, 2). This project has come a LONG way since its relatively recent inception, and is an impressive work melding OpenOffice with the Mac OS X look and feel. There's more work to be done, but the latest 1.1 development release is impressive.
Fifth, there are gargantuan technical hurdles to maintaining a full Aqua port of OpenOffice without greater engineering support (perhaps from the likes of Sun, who has shown zero interest in maintaining OpenOffice for Mac OS X, much less maintaining a commercial StarOffice for Mac OS X). These are all detailed here, incidentally by one of NeoOffice's chief representatives.
So calm down. This isn't an Apple conspiracy, or the end of OpenOffice for Mac OS X. OpenOffice will continue, in X11 form AND in the likes of things such as NeoOffice. If anyone is to blame for the official OpenOffice.org Aqua port going by the wayside, frankly, it's a lot closer to Sun than anyone else.
The x11 port works as well as it does on other platforms, i.e. it's great unless you want ms-office compatibilityl. The OSX port would add eye candy and a more conventional OSX "feel." I suppose it would also support fonts (which mac users have in massive numbers). But would these things be enough to make users switch? I think not.
Folks who want full ms-office compatibility will use ms-office or, perhaps, the upcoming iWork. nd folks who can live with something that is not ms-office compatible (and I stipulate that OO is not) will probably be just as happy to use the existing x11 interface.
Me? For committee work (which demands ms-office compatibility), I'll use ms-office. For presentations I'll use keynote, unless I'm sharing it and therefore using PowerPoint. For my research writing I'll use latex. For my friends I'll use a fountain pen. Hm... OO doesn't fit in anywhere :-(
You can't ignore the largest Unix vendor in the world: Apple. You're just cutting your own throat if you ignore a huge segment of the market for your software. Projects succeed when people USE the software.
That's why. It's not native to Aqua and it shows. Mac people like polished apps, and Qt apps simply look like they've been poorly ported from Windows.
Not as a rebuttal, but as an inquiry:
Is there a good compiler (open source or otherwise, but for the major platforms) that will turn Java into native code without requiring a virtual machine?
I don't see why one shouldn't exist, but I haven't heard much about one.
http://www.ragtime-online.com/ it beats Openoffice hands down. just my ,02
The java-nised NeoOfficeJ is the project you're talking about. It runs in darwin and works. The official openoffice requires xdarwin and runs as good as your X.
i've been a Linux user for about 10 years and a Mac user for about 2. when i went to install OpenOffice on my ibook i had to jump through hoops i hope to never have to jump through again.
So bad where these hoops that i've pretty much tossed OO (using X11) and am using NeoOfficeJ with fairly good success.
If the OO team wants Mac users to migrate from MS Office to OO it would probably be smart to focus some time and energy on a native port. Very few people are willing to take all the necessary steps to get OO running on OS X with X11. not only that but it's slow, doesn't have nearly as nice an interface, and DRINKS DOWN the memory.
nature loves variety::society hates it get your variety at http://www.monkeypantz.net
Ask Microsoft how well Word would be accepted if it didn't follow the basic UI outlines of the Mac OS. There used to be a time when Word (and all Microsoft products) made up their own key combos, their own look and feel and were generally willy nilly -- a lot like many X11 offerings now. Word was the same on Windows (albeit 3.11) and Mac (6 or 7) but it didn't play well with the other programs.
As a tech support, do you think you'd get more questions from people about why copy and paste doesn't use the same buttons on the Mac/PC/Linux versions or do you think users are more likely to not understand this one program that doesn't act anything like the other Mac programs? How many users are going to hop from machine to machine versus program to program? And then consider that it is just a word processor. Screw it. I wouldn't want those support calls.
This has been the downfall of many otherwise fine pieces of software on the Mac OS. It's users expect consistancy.
I looked at OOo with the thought of helping out with the native port, but recoiled when I actually looked at ths sheer size and complexity and skill necessary. Another important point in the linked post is that moving to Aqua will take "a couple thousand hours of developer time," which I actually think is being optimistic. Unless an experienced somebody or, more likely, team of sombodies is willing to put their nose to the project 40 hours a week, like it's a full time job, it's not going to happen. And even if it does happen, it will break compatibility with the rest of OOo.
OOo, I'm sorry to see you go. At this point it might be easier to start from AbiWord and move out to develop a full office suite on the Mac. The tension between being "Mac-like" and coordination with the rest of OOo -- which isn't anywhere near as mature as MSO, yet, anyway -- is too great.
First of all, we have some nice, juicy, out of context quotes like this one:
no MacOS X work has been done since 2003
when in fact the page linked to states:
all engineering for OpenOffice.org Mac OS X has been focused on X11 graphics, that is, OpenOffice.org Mac OS X (X11).
Then, faithful Slashdot reader, we are informed that: there are no longer any plans for an Aqua version 'due to various licensing, political, and fundamental engineering difficulties'. :(
When in fact, although there will not be an official OOo in Aqua, there is this:
For the last year and a half all engineering work focusing on a native Mac OS X OpenOffice.org version has been concentrated in the NeoOffice/J project, using a combination of Java and Carbon technologies to replace X11.
So you can just use NeoOffice/J
So basically what we have are a group of developers not willing to take the time and effort to go headlong into learning a specific OS's nuances and tweaks, and majority reworking the code to run natively in OS X, but who will keep making an X11 version that keeps up with the other platforms, and there is a 2nd set of developers working that into a native port. Doesn't seem like the end of the world to me.
So have no fear, OOo is here to stay on OS X, and NeoOffice/J is here to work on a native port.
e to the pi i plus one equals zero
Also, he claims
... huh?
Large animals, such as sheep and cattle, are used to convert captured solar energy into a form that humans can use
That's what plants are for buddy.. Large animals then convert the hard earned energy of the plants into useless gasses, heat, sound and a tiny bit of food.
If you want sustainability, get rid of the big animals. In fact get rid of the chickens, too.
stuff
WTF?
Obviously, this is not a C portability issue. It's an issue with proprietary GUI APIs.
If it used some standard GUI abstraction layer, it would have been a simple port (as seen with the X11 version, which was easily ported to MacOS+X11 -- how's that for C portability?). But, the port to a different GUI would take much more effort. Unfortunately, the developer resources just aren't there for a native UI port (most of the relevant developers gravitated over to the MacOS X only, Java based, NeoOfficeJ instead).
One problem with this is that X11 is not installed by default in Panther. You have to choose "Customize" and then click on X11. As most people don't know what it is for, most will not install it. This, more than perhaps anything else, is a hurdle for basic Mac users.
I really was hoping for an Aqua port that worked well. X11 is just a bit of a pain for those who thrive on Apple's consistent UI.
iWork looks nice (I played with it more than a bit at MacWorld this week), but I would prefer OO in Aqua (Pages, to me, seems more of a page layout tool than simple text editor that replaces Word).
In short, there's still plenty of options (even TextEdit is a fine basic editor), but I had really been hoping this would come through. Let's hope that things may change and a port comes through in the next few years.
http://www.apple.com/opensource/
How do you like the contributions to KHTML that Apple provided? What about the PPC additions to GCC?
They are fully compliant with the licenses of the software they use and modify. Did they have to give the Streaming Server to Open Source? No. Did they have to open source Rendezvous? No.
Jesus was a compassionate social conservative who called individuals to sin no more.
Check out NeoOffice. They seem to be doing just fine. Help/funds from Apple would certainly not hurt, but I'd say the "native-looking" OS X oo.o version is here to stay.
They wouldn't be able to do it right anyway. Seriously, a lot of people are under the misconception that Aqua is a set of nifty-looking widgets. It's an interface standard for clean apps.
If your app has some shitty Office-like toolbar consisting of a row of 20 NSButtons, that's a shitty design. If your app's preferences are organized into 3 rows of 10 tabs each, that's a shitty design. If you can find the same function in 4 different places, that's a shitty design. Doesn't matter if it has an Aqua titlebar and Aqua buttons. Look to Office 2004 as an example of how Aqua cannot save fundamentally bad UI design. The OO.org guys would've just made the same mistake.
Openoffice is a great office suite, but it reminds me of mozilla, what we really need is a set of re-engineered applications with the same core (smaller-lighter-easier just like mozilla's firefox and thunderbird).
_________________________________________________ Just another Crazy Linux/Perl Maniac
So there could be as many as three OS X versions -- NeoOffice/J, X11 and "native." With different license possibilities for each. It gives me a headache just trying to keep it straight on paper, let alone trying to somehow coordinate all three of these efforts.
Not that I've ever heard of, but why do you want to turn something generic into something not generic? I guess I can see why someone might want to do that, but once you go that route you have the same "We depend on exacly these versions of these libraries, and woe betide the fool who attempts to use a newer or older one..." thing going on.
I guess I"m a bit cynical, as I deal with vendors all day, and they give me the same BS that all the OSS zealots do about native code. I can't tell you how many times we've had a box go down only to find that the sort of hardware/software that can actually run this POS program just doesn't exist anymore. We must have 30 different system configurations at work, I know we've got a few one-offs just specifically to run some native program that a vendor gave us a couple years back.
What happens if one of those one-of-a-kind boxes goes down? Can you get an old US-II running a 3 year old version of solaris with exactly these 50 libraries, and can you get it quickly enough that the company doesn't go out of business before you can bring that thing up? This is probably the single biggest problem with native code, it's HELL to support, but it's even worse if you have to try to integrate with it programatically.
We never have exactly the same compilers/libraries as our stupid vendors, so we can never programatically integrate with thier software, it always gets reduced to passing around files and socket calls, I don't have to tell you what a hoot that is. It's actually possible (and not that hard) to integrate with these things through CORBA, but our sucky vendors usually make that impossible. Even then, it solves the second problem but not the first one.
So, the choice is clear. If we let our vendors give us native code, then we need to plan on having 50 system configurations, and a couple of EXACT duplicate spares of each, as well as dozens of different development environments perfectly suited to each sucky program, or a horrible file based API.
Alternatively we can just require that it's Java or it doesn't get in the door, and then all these problems are gone. If a box goes down, we just replace it with any equivalent hardware and are pretty confident that it'll work. We can also call the APIs directly, as we won't have compiler/library/calling convention mismatches. Even better, if it crashes, we might get a useful stack trace as opposed to merely a core dump and a dead program.
I also must say that the shops that write in JAVA are hugely more cluefull than those that don't. I've worked with and worked at both types, you either understand the above situation, or you don't. You never want to work with or for anybody who can't understand the scenarios layed out above. At work, we are (fortunately) doing a good job of keeping native code out, though there's still a little bit here and there. We are going to add another piece of native code it looks like, but it's either that or buy something from Reuters, and in this case it appears that going native by not-reuters is better than getting anything from Reuters.
Has anyone tried hiring a MacOS X developer or consultant to port OO.org to MacOS X? It seems like a native OO.org isn't really desired if all people do is complain that a nativa MacOS X OO.o doesn't exist and someone else won't do the work for free. Perhaps a bunch of MacOS X users would be willing to chip in US$20 to pay for something that can get the ball rolling.
Digital Citizen
See some of the earlier posts, but in general:
It's a hassle to use X11 under Mac because you must start up X11 and then OOo. Additionally, the menus do not behave as other Mac menus do, and the integration to the rest of the desktop isn't perfect.
Aqua is the name for the most current display widgets for Mac OS X. Quartz is the video display technology they're built upon. A native Aqua/Quartz application uses the Mac OS X desktop natively, without going through an X11 server that sits as an intermediate.
There is a certain amount of logic to the idea that they should focus on X11. But the truth is that if Apple really wanted an Aqua version, there would be one. Apple has been known to be rather snobby, and they're probably suffering a bit from the NIH complex, because they're working on their own productivity suite.
It's kinda like expecting really good support from Apple for Mozilla when they'd rather push Safari.
Well, I do understand their reasoning, and as others have pointed out, Apple will always be a "niche market" for OOo.
Of course, as a mac user I am somewhat pissed off that the platform is being relegated to the status of a second-class citizen. OSX X11 takes quite a while to start up, and incurs a NOTICABLE overhead compared to the Windows native version of OpenOffice.
Also, on a platform that makes it name based on simplicity, having to install X11, with its cumbersome (and possibly confusing to users with no *NIX familiarity) configuration choices may drive users away.
On the flip side of this coin, Apple's iWork suite may get a boost from this (OpenOffice will never be native, iWork is native & integrates seamlessly with the rest of the iEverything world), which will help Apple's bottom line - so this isn't all bad.
Still, I was hoping for a native OpenOffice in v 2.0. Cest' la vie.
/~mikeg
I personally feel that while in an ideal world Java would be good solution, I'm not convinced its the answer to all the world's software portability problems.
ANSI C is very portable. It's also utterly useless for things like GUI applications, unless you feel that writing your own GUI toolkit and low-level system interface is fun. Portability problems are introduced by the system APIs and GUI toolkits used to do interesting things - not by the language.
Java provides a standard GUI toolkit, plus some very good abstractions of platform APIs. If, however, you want to go beyond those platform APIs, you're back at square 1 - re-implementing the platform service, or writing an interface to it to abstract it for cross platform use. Bang! Your Java app just ceased to be portable.
To get the sort of OS integration the mac users rant about, I'd be very surprised if you didn't have to write a few extensions for platform API interfaces.
Another issue with Java is the GUI toolkit. IMO Swing is clunky, ugly, and gives everybody the SAME poor "user experience". Even tools like JEdit that I've seen held up as examples of how well things can work feel pretty painful in my experience when compared to a native app. I'd find Java a lot more interesting if Sun would bite the bullet and put their weight behind SWT.
In the mean time, I'll be sticking to C++ and Qt - IMO the next best thing for portability, and much better when it comes to GUI work. Of course, Qt borrows liberally from the Java APIs where they're good, and I'll for that.
As for Mozilla, I'm pretty sure they implement their own GUI toolkit - not a window system. I'm with you on the slow RAM hog, though.
I'm not one to argue that Java is fast, but IMO until they Sun addresses the Swing albatross Java won't be a viable first choice for implementing serious GUI applications where "user experience" is a major concern.
On the Mac platform, there's Microsoft Office available natively, and now Keynote and Pages. OpenOffice arguably competes with MS Office essentially only on the basis of price, not by being better. However, people who buy macs have already demonstrated a willingness to pay a premium so that things "work". Therefore, it's not worth the manpower to maintain a native port for a small percentage of a small market. I keep MS office around solely for opening other people's files, and use LaTeX, Matlab, and the Adobe products for preparing documents.
Firstly the anouncement is purely for the Version 2.0 codeline. This is an excellent idea because it focusses everyones attention on getting the best Mac Port possible in the timeframe, not scattering resources trying many things.
The Mac effort is one of the most intense efforts in OOo today by FOSS developers. There are many volunteers and almost daily offers for additional help. So as they say, news of my (OOo) death is premature.
Ultimately the NEO office port will be merged with the mainline OOo. At this stage there are some issues with doing this cleanly so it is managed (extremely well) by a third party. This will continue until the whole thing becomes clean enough to merge. Try NEO if that works for you that is still a win for OOo in my book, I do not care about the brand name frankly my effort in making OOo better in a number of small ways is paying off, I am proud.
Finally do not forget that this is an Open Source development. Any predictions that something will not happen are just very unlikely because someone with a bee in his or her bonnet will do what you do not expect. If you want an Aqua port more you want a serious stable Office Suite using X on Mac then please by all means, do that.
Everything parent says is absolutely correct, just apart from one little thing. MacOS X automatically starts X11 when you run an X application. The launcher does this by looking at the libraries that the app links to.
I use several X11 app under OSX and it functions great. However, native Aqua apps are generally easier on the eye.
All interpreted languages are abstractions over Lisp
Yes - the Compatibility page for Pages says
and the Compatibility page for Keynote 2 has a table showing that it can read and write PowerPoint presentations.
Nothing about Excel spreadsheets, but given that iWork doesn't have a spreadsheet....
Engineers need spreadsheets to draw graphs? Custodial engineers, maybe. REAL engineers use things like MATLAB, MathCAD, etc. to draw graphs. If Excel lets you graph on log-log and semi-log scales, I haven't been able to find it - and, for that reason, I haven't tried to find it in a while. Got better things to do with my time than twist a spreadsheet into being an engineering application. REAL engineers don't predict the demise of any competitors, that's what marketing pricks do.
Besides which, NOTHING about OpenOffice or MS Orifice requires ECC or a workstation.
When it comes to engineering documents, a combination of LyX, XCircuit or XFig, and MATLAB beats the shit out of Excel and Word any day of the week. I think I'd quit my job before I tried to write a real, equation-heavy engineering document in Word. LyX just has a better EQ editor hands down. And there's a native OSX version of LyX.
What's needed to establish Macintosh as "the premiere engineering workstation" platform is ENGINEERING APPLICATIONS. PSpice, MathCAD, a decent version of MATLAB, various FEA packages, etc. Vendor support in the form of OSX-native tools (Altera, Microchip, are you listening?). Obviously I'm EE-biased here (being an EE), but I'm sure that the ME, ChE, and CE guys can provide a similar wishlist. How about an OSX version of Autocad? THAT would sell some Dual G5 boxen.
Processor architecture is really irrelevant here. It's the OS that matters. Autodesk, say, can easily recompile a Unix version of Autocad to run on SPARC, AMD64, Xeon, P4, MIPS, or PowerPC once they develop the Unix version . Now, it may not be completely straightforward to turn that into a native Aqua version, but it's gotta be easier than converting the Windows version to Aqua.
Ce n'est pas un vrai mouvement de robot!
First, this isn't a surprise. They announced a while back that they might not even have an X11 port of OOo version 2 for OS X. While it is kinda crappy that they are completely abandoning it, there isn't much they can do if they don't have the developers.
As for their reasoning that an X11 port is better, it is completely flawed. Firefox shows that reason 1 and 2 are bogus as it is to market at the same time on all platforms with equal stability, reason 3 is actually a draw-back that they are trying to market as a feature (gotta love the Microsoft-ian logic there), and the last one is basically a way of stating that we already have an X11 port so it means less work for us. If any of these were valid points, Windows users would be running it in Cygwin right now. They're all just a way of saying "we don't care in the slightest about your platform, but we don't want to look like we don't care." Frankly, if you don't care, that's cool. This is your work. You don't have to support Mac OS X if you don't want to. Anyone is free to come along and pick it up if they are interested. That's what is so great about free software. Just don't trip me and tell me you did it because I looked lonely and you thought I could use a hug from the ground.
More importantly, OOo just isn't that good. It's amazingly slow and ugly, uses a fileformat that takes forever to save and creates huge files, and just plain worse than the other options out there. It's why there haven't been a lot of developers flocking to it from the Mac community. Something like Adium gets developers because it is the best. It's fully native, it's fast and clean, etc. There are a lot of other OSS projects on the Mac as well that are all good projects. OOo, by comparison, seems to employ a pretty terrible codebase and interface. While it has more features than AbiWord, AbiWord is clearly a better base. When you add Mac uses tendency toward well-done software with the fact that Mac users also don't mind paying for software as much as users of other platforms (lets face it, even Windows users don't pay for software - they pirate it), it means that OOo on the Mac doesn't have as much interest.
One of the big problems is that OOo only has the "free" aspect to draw users. WordPerfect Suite and Microsoft Office are still much, much better applications - this is coming from a user whose computer only has Ubuntu on it, not some OSS hater.
I've come down pretty hard on OOo here, but as a long term Mac user and now an Ubuntu user who loves Gnome, OOo is just terrible. Now, if you want the most featured office suite available, OOo is a great option for you. For a user like myself, and most Mac users, the features of OOo don't make up for the bloat and interface. Things like AbiWord and Apple's new Pages are much more attractive options even though they do less. Hopefully, OOo will become better in the future (I've run some of the 2.0 previews and wasn't that happy). Maybe AbiWord and OOo will start to converge toward each other like mySQL and PostgreSQL. But until OOo cleans itself up a lot, there isn't going to be the interest needed to bring it to the Macintosh because of how Mac users like their applications to work.
You should read Apple Human Interface Guidelines. For your reference, toolbars DO NOT look like this in Cocoa. Also, UI elements are not placed at random within Aqua. Apple Interface builder shows dynamic guides when you place controls, and these guides help you to comform to HIG. Items should be aligned. Push buttons should have descriptive text on them, there should be sufficient spacing between UI elements.
Merely using Aqua controls is not enough.
Don't blame Mac users if you don't write an application to look like the platform you put it on.
You wouldn't write an Apple IIe-type program for Windows and expect people to think it looked nice.
Why would you expect to write a program for one type of GUI, port it, but keep exactly the same interface, and expect the people on the second platform to think your program works very well?
Programs on different operating systems should not look exactly the same. If you have a program for one OS that looks like it was written for a different OS, you can expect people to see that application as a half-attempt, and you can expect them not to regard the program very highly.
And as for open-source on the Mac OS, most Mac users I know love open-source software. I have nine open-source applications in my dock right now, and numerous others on my system. Most of them have been much more successful than OO.o. I would say that 99% of the problem OO.o has on the Mac is that it doesn't look like other Mac programs and doesn't try to.
Most Mac users don't want to run second-hand programs, and second-hand is exactly the impression OO.o leaves on the Mac.
I was really looking forward to an Aqua port of OO.o.
Albuquerque PC
How expensive is Apple's PowerPC?
I bought a whole skid of PowerPC Macintoshes (beige case) at auction last summer for a dollar.
"What's the frequency Kenneth?"
I always look at these threads with amazement. How can anyone really believe that a major corporation supports OSS for philosophical reasons? They do it because of basic economics, which they expect to benefit them in the long run. Typically, they are attempting to commoditize software on a particular hardware or OS platform they control, in order to increase the value of their position in that hardware/OS market, or more likely today in related service sectors. It is not surprising at all that Sun won't divert resources to support OSS on a competing platform!
It's also amazing that a few OSS evangelists can still chant the "if you don't like the development direction, you can just fork" mantra and maintain that OSS is future-proof and highly portable on this sort of basis. To an impartial observer, it's obvious that most of the major OSS projects (from Linux on down) are developed principally by a small number of commercial concerns, who have those same reasonable economic drivers for doing it. Unfortunately, it just isn't realistic for a handful of individuals who haven't been involved for a long time to pick up projects on this scale and carry on development. It has never been a good situation in the commercial, closed source world, and just opening the source to everyone (typically laughable documentation and testing included if you're lucky) doesn't make it any more likely that it will happen. Sun apparently understands this, and knows that in reality they still have far more control over StarOffice/OpenOffice development than anyone else, and will therefore use it to their advantage if they're even remotely smart.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I had been using an ancient version of MS Office on System 9 under OSX. I decided it was time to move forward, but really did not want to support Microsoft. So, I installed OpenOffice and gave it a try.
In no time at all my Office needs were resolved. OpenOffice ran like such an ugly slug that it overcame all my Microsoft objections. I immediately bought MS Office for OSX. Without the OpenOffice experience I could never have been happy buying a Microsoft product.
Thank you, OpenOffice team, for peace of mind.
Agreed.
Short version:
More people run multiple apps on one platform than run one app on multiple platforms.
Appendix:
Dur.
Why would you expect to write a program for one type of GUI, port it, but keep exactly the same interface, and expect the people on the second platform to think your program works very well? Programs on different operating systems should not look exactly the same. If you have a program for one OS that looks like it was written for a different OS, you can expect people to see that application as a half-attempt, and you can expect them not to regard the program very highly.
The success of iTunes for Windows suggests that this is not universally true. I know some people who avoid it because the interface is weird compared to what they're used to, but there are plenty of people who really don't seem to have any problem running something that looks like a Mac app on their PC.
I fucking hate you, dude.
...
How the hell did you pull that shit off?
And wanna sell one for $2? 100% profit! Can't beat that!
+++ATH0
If you're referring to Apple's iWork that was announced last Tuesday and will be available this Friday, I don't think it really counts as an "office suite." It's just a word processor and presentation software. I suspect that they'd have to at least include a spreadsheet for it to count as an office suite.
I'd be very surprised if they don't - but they're focusing on one piece at a time (Keynote, then Pages, then...) and releasing them that way, instead of developing them all at once (spreading resources thin). I'd expect a spreadsheet to be next, then a database - perhaps a front-end to SQLite.
So if it is based on OOo in some way, they did a phenomenal job at fixing it up!
It isn't. It was easier for Apple to start from scratch, than to add a nice UI to OOo. Besides, they'd have to release it as open-source, and they'd rather charge $79.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Sure, it is java, but NeoOffice/J is a pretty nice non-X11 dependent OS X port of OOo, complete with an aquafied menu, and continued development. Check it out: http://www.planamesa.com/neojava/en/index.php
http://www.sampletheweb.com
But it works, and since we got so fed up with different file formats at home and switched everything to the free OpenOffice XML (OASIS) format, this is what counts here. Those of you who think OpenOffice XML is some isolated open source thing should keep in mind that the European Union (400 million people and counting) is probably going to make OASIS an ISO standard (Sun is pushing this like mad), and that open source projects of all kinds are converging on it as a common standard: Koffice is the biggy next to OpenOffice.org. The standard is here to stay. If you want to play the game, sooner or later you either have to have a monopoly or support it.
Which brings us to the reason why this new announcement is more of a problem for Apple than for the average Slashdot user: The OS X platform does not offer a free full-fledged office suite. AppleWorks is a joke, basically one of those toy apps left over from when they had that toy operating system OS 9, and iWorks is neither a full suite nor does it support OASIS. And there is no way I am going to pay for Microsoft Office, since it does little more than OpenOffice for some ridiculous price. I mean, when it comes down to it we're talking about the choice between buying an iPod or buying Microsoft Office. Duh!
I've said this before and I'll say it again: Apple should do a Safari (Darwin, Cups, GCC...) here and admit that they can't produce a first rate office suite by themselves. Keep Keynote if you must, but get the rest of the people wasting their time with iWorks behind an Aqua OpenOffice port. This would rid Apple of the last area where they are dependent on Microsoft, and give them the office capabilities the Mac currently lacks.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Fundamentally, I agree with you. I like it when I have small utilitues that do small things very well. I've burned a lot of CD's using cdrecord, for example. (Mainly to make boot CD's for my dreamcast - I have yet to find a slick integrated monolithic GUI app that makes developing boot CD's for obscure platforms a convenient thing...)
Now, let us ponder for a moment... Not everything is done best by small command line utilities. For example. Let's suppose that you have PowerPoint, or a PowerPoint type clone. It makes sense for it to be a fairly monolithic app. But, it also makes sense to be able to script your presentations.
The Windows way would involve VB. So, no right thinking person need consider the Windows way.
The Linux way would involve exposing as much as possible of the GUI to the command line. Possibly inventing some sort of scripting language. It would sloiw development, because it would require substantial resources to impliment well, and keep current with the GUI, and make all GUI functionality available to the command line API.
The Mac way would, naturally, be AppleScript. The develoiper doesn't need to make a bunch of little utilities to go along with his monolithic app. He doesn't need to maintain an API. Adding Applescript requires a tiny amount of work for a native app. It exposes large amounts of functionality conveniently. In the hypothetical presentation app, it would be trivial to allow the scripts to set a presentation to have as many slides as there are images in a directory, and add text on the slides extracted from EXIF data in the JPEG's, and then overlay some lines and such, and set random transitions between them all.
Sure, you could just use ImageMagik to add text on top of the slides, and add some graphical elements, and save them out as a different set of JPEG's, but if that isn't what you want to do, it doesn't help you. Sometimes you really want to use a monolithic app because it is the right tool for the job, and no amount of chanting UNIX mantras will cause your spplications to change into something else, and more than a Windows user chanting his mantras will turn sed, awk, and teco into a monolithic friendly GUI application.
By having a sane systemwide scripting language, you have the ability to make use of those monolithic GUI apps, and still use the little utilities (in my above example, you would probably use a "classical" command line utility to get the EXIF data to tell the presentation program to put on the slide)
I am reminded of a time years ago when I was in France. A certain wineseller refused to sell to me because my French was good enough for him. Somehow it seems that you're embarassed that I don't speak perfect Mac. I get the sense that you wish I had never ported my software to the Mac at all. But I have lots of letters of gratitude from Mac users that assure me I made the right decision.
Maybe my application isn't a native Mac app, so what? At least I speak Mac well enough to be understood. Maybe I've got a slight accent, so what? I'm covering a market niche that no one else in Mac-land has bothered to cover. Before my Qt/Aqua port all my Mac users had to perform painful contortions with Fink and XFree86. If you think my Qt/Aqua port has an unacceptable accent, you should have seen it when it had a Motif accent!
No, I didn't use XCode. That's because I use Emacs and GCC. Heck, I didn't even know XCode ran under FreeBSD. In any case, I could have redone my interface to make it adhere better to your sensibilities. And I could have done it in Qt/Aqua. But that interface would have been so different from the X11 and Windows interfaces that I would have had to either fork the code, or befoul it with scores of additional #ifdefs (and the resulting illegibility and unmaintainability they cause). I could have done this. But Mac users would have had to wait a lot longer to see the finished product.
I'm not claiming that my application is a perfect example of Mac ideals. I merely claimed that you couldn't tell it wasn't developed natively. Your initial impession that it was a Carbon app validates my point. If I would have spent the extra time to fix some niggling minor "foreign accents" in the interface, I could definitely have made it look as if Steve Jobs himself has written it. And it still would have been written in Qt/Aqua.
But I don't even own a Mac. Which is why I think my porting attempt is pretty damned good. Even if it pisses off elitist French winesellers.
Don't blame me, I didn't vote for either of them!
I first tried NeoOffice/J a year or so ago. It was huge, took forever to boot, and ran dog slow. I wondered: why on earth would anyone rewrite a beast like OO.org in Java?? Didn't realize the Java part was a lightweight wrapper around the OO core.
Anyway, I went back to using OO.org X11. It's huge, and runs pretty slow, and looks like crap, but it works. The Start OO.org AppleScript launcher, which provides an icon to start OO.org, and also provides support for OO filetypes with icons, is a nice supplement.
After seeing this today, I tried the current version of NeoOffice/J. I didn't realize it was this far along. A real Mac menubar! Aqua print dialogs! Starts up reasonably fast! No X11 required! Compared to OO.org X11, this is already a native port. Yes, it has a little further to go, but my gosh, what a good job for a project with two or three developers.
Great job, guys!