Slashdot Mirror
OpenOffice 2.0 Preview Release
gmuslera writes "A preview release of
OpenOffice.org 2.0 was released, which has new
features like better MS-Office compatibility, an Access-like program and a more. Here is a review
of it with screenshots and how it performs. It's work in progress, maybe not recomended for production sites, but it is a good sample of what is coming."
the OS X support is coming now, but they need help.
I am the Alpha and the Omega-3
They are looking for people to help on the project that is going to create the OS X native support. Head on over there if you want to help out. Should be an interesting project.
"Access-like" is more specific. If they had just said "database" it could have been a wider range of applications. "Access-like" specifies that it's used like access.
MySQL is a database, yet I hardly think you'd call it "access-like".
Pretty easy, Sun bought StarDivision a German company a few years back. That company had an Office like Suite called StarOffice, at that time in version 6.1
.org) and keeps a supported, shrinkwraped version with the same sourcebase as StarOffice. The two applications start in Sun's world as StarOffice 7 and OpenOffice.org 1.0 respectively.
A few months after buying StarDivision, Sun opensources the commercial application under the brand OpenOffice.org (notice the
Now it is logical that the StarOffice versioning keeps keeping pace with OpenOffice, as it is basicaly the same application minus templates and support. From a marketing point of view keeping two brands makes sense.
There is much more history to StarDivision than this, but that is another story.
Cheers!
Further, if one ever hopes to convert the great, unwashed masses from MS to OS, they will expect to have an office automation suite that acts just like it did on their Windows box.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
From the article:
Load speed is one area worth noting because of the improvements over previous releases. Launching the Office Suite installed on winXP Home SP2, with the program's "Quick Starter" feature disabled, produced the following results: OpenOffice Writer loaded in 10 seconds. The Spreadsheet (OO Calc) in 11 seconds. The Powerpoint-like presentations module (Impress): 9 seconds. OO Base (a new database program): 5 seconds. With Quick Starter enabled: OO Write: 3 seconds. OO Calc: 7.5 seconds. OO Impress: 6 seconds. OO Base: 2 seconds.
We never use the actual Access database here. We just use it as a front-end. I'm glad to see an 'access-like' program in OpenOffice. We could use a nice free front-end to talk with a 'real' database server. Not just some lightweight database that comes as a part of an office suite.
If you want to make sure your resume comes through clean, PDF it. No subtle MS-Office compatibility issues, you can use whatever you want to create it (OO.o, SO, LaTeX, etc).
I want to delete my account but Slashdot doesn't allow it.
...Now I have to change them in Google's Desktop Search again.
I hate stupid rules... Rules that make sense I don't mind... But the stupid ones just really bug me!
This might answer some of your questions:
http://wp.openoffice.org/
hsql
pr0n - keeping monitor glass spotless since 1981.
Why are you sending resumes in Word format instead of PDF or RTF?
I have never had my resume available in Word format - and it's never caused me any problem.
If they want it for printing or viewing, send a PDF; if a recruiter needs to massage it to their own format, they get the RTF or HTML version that they can import. (Send an RTF and most people won't even understand that it's not "Microsoft Word format".)
This not only avoids promoting the use of software and proprietary data formats from a criminal corporation notorious for poor quality, it has the very real practical advantages of reducing version incompatibilities ("Office XP? Sorry, I only have Office 97...") and the risk of spreading viruses.
It's the right thing to do, and the tasty way to do it.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
If you have to resize your text to get all the bullet points to fit on one slide then there's something very wrong with your presentation.
I do believe there's some maxims that should be applied to presentations... one of them is never have more than 6 bullet points on each slide.
Another is that if the text for a bullet point spreads over more than one line, then it isn't very pointlike now is it and should really be examined to cut it down.
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
On my laptop with a slow 4200 rpm hard drive AbiWord takes about 2 seconds and MS Word takes about the same.
Abiword is very lightweight and far from being as feature-full as OO.o . If it does everything you want, you might as well stick with it, though.
As for MS Office, it loads that fast because it pre-loads in RAM at startup. You can do the same trick with OO.o and it'll load in a second. The loading times in the original article were WITHOUT the pre-load.
Treehugger? Treehugger... Treehugger!
FRom what I've seen poking around the site, native Aqua/OSX support didn't quite pan out for 2.0 the way it was supposed to. It looks like it still requires an X server, and still uses its own toolkit instead of aqua or a smart approximation.
Neooffice/J was the proof of concept to bring OO 1.x to the Aqua system. It looks like they made some progress - using Aqua widgets and controls in some places, but only a few, and doing away with the need for an X server. But it doesn't look like they've gotten much farther than that, or readied 2.0 to be aqua-native. That's a shame.
Here's your answer: http://porting.openoffice.org/mac/
Disclaimer: I am one of the community members of the Mac OS X OOo "team" and founder of the NeoOffice project
It will probably be a while before you can even see X11 support for 2.0. Eric just got the 2.0 X11 based code to *compile* for the first time yesterday and it won't even run as setup crashes.
Part of the problem is that OpenOffice.org really isn't a "team"...it's primarily Sun Microsystems. Sun has four priorities: Linux x86, Windows, Solaris, and Solaris x86. Sun pays no one to work on Mac OS X support. Since it isn't one of their priorities, they frequently code without keeping the special needs of Mac OS X in mind, doing stupid things like hard-coding shared library extensions to only be ".dll" or ".so", neither of which are used by Mac OS X. They can't claim ignorance since folks have been trying to write Mac OS X code for over three years now, but yet they still don't even keep simple compatibility needs like that in mind.
Getting true native support for OOo without X11 on Mac OS X is most likely not going to happen within the OpenOffice.org project. All of our native work has been going on in the NeoOffice/J project. It uses a mixture of Carbon and Java to run using ATSUI for native fonts and Quartz for native drawing and printing. We also use full GPL licensing so we can incorporate the good work of contributors who can't get their translations and patches into OOo due to licensing and politics.
The process of giving it Aqua widgets has already begun. The latest 1.1 Alpha patches use native Mac OS X menubars. Aquafication is slow, though, because our first priority is to make it functional first, then make it pretty second. It doesn't matter if it looks pretty if it crashes after 5 minutes!
For what it's worth, it's already taken over two years just to get NeoOffice/J to the point where the native Mac OS X support is functional. By functional I mean that it can copy and paste both formatted text and images with other Mac OS X applications, has correct fonts and font layouts, functions with most all of the Mac OS X printer drivers, launches properly from the finder, works with the scrollwheel on those funky mice some Mac users have, has an integrated WordPerfect filter, uses the Apple Installer, has automatic upgrade notification, automatically translates the interface based upon your preferred language in the System Preferences language pane, etc.
OpenOffice.org 2.0 X11 has no native non-X11 support in it, much less the level of integration with Mac that we've achieved with NeoOffice/J. It's taken two years of some really dedicated engineers (namely, Patrick) to get NeoJ up to that stage. Replicating all of that work within OOo will probably take nearly that long and perhaps longer if the experts aren't there to help.
NeoOffice/J is in fact OpenOffice.org 1.1.2, and is 97% identical on a source code level. It's even got bug fixes that aren't in the OOo GM (such as functional JDBC support). This week we're going to be taking NeoOffice/J to 1.1 Beta after all known crashing and deadlocks have been fixed. And...
NeoOffice/J 1.1 Beta will be based off of OpenOffice.org 1.1.3, which isn't even available for Mac OS X X11!
Just keep up to date on the latest Mac OS X porting news on trinity instead of the infrequently updated OOo pages. RSS feeds are available too.
And don't let all of the politics and scare tactics of the OpenOffice.org denziens scare you either. NeoOffice really is the 'official' place for Mac OS X native OpenOffice.org and is where all of us core developers work (Patrick, Dan, and Ed).
ed
This version of OOo Base can do exactly that. The only parts of an MDB it doesn't work with are the forms/reports/macros. Tables (internal and linked) and queries are opened seamlessly.
Disclaimer: I am one of the members of the Mac OS X OOo team and a founder of the NeoOffice project
OpenOffice.org X11 on the mac is effectively dead because it is horrendously understaffed. There are less then 5 people actively working on it. Not good for an 8 million line + application.
While Apple's developer documentation may be first class, OpenOffice.org X11 is not built using Apple-specific technologies. It is built from the command line and is using X11 with its own internal widget toolkit. Oh yeah, and takes 9 hours to compile on a dual G5 2GHz. That hurdle is a bit too high for just someone to stroll on in and casually check out the project.
OpenOffice.org is a large and thorny Unix application. There are very few Mac OS X programmers that actually have X11 and Unix skills and the patience to deal with something of its size. Most developers come to the project and are like "can I build it in XCode" or "can I use InterfaceBuilder", find out they can't and then leave. The lack of a sufficiently large pool of skilled volunteer programming experts effectively killed OOo on the Mac from the start.
The native work has effectively moved to the NeoOffice/J project, which is 95% code identical to OpenOffice.org and uses Carbon and Java instead of X11. It still doesn't use Apple development tools directly, but it does have two of the original developers of OOo Mac OS X working on it continuously.
ed
No, they just did it to indicate that it is a alpha. In Germany many IT newsmagazines published betas of OO 1.0 as "OO 1.0", so that has to be avoided. Users shall not get diapappointed by prereleases.
A sticking point is that Apple probably can't get a perfect .doc file importer (nor can MS) and Apple really really likes to have everything work flawlessly or not at all.
.doc files as it is now. I haven't tried to open anything complicated in it so I can't say for sure how well it handles it. They would at least have a starting place.
I believe that TextEdit will open
Not everything is analogous to cars. Car analogies rarely work.
and many many more things. All of those tasks are huge. The first wasn't an issue for Linux but the rest were, and the work has been done primarily by Red Hat and Novell working together, as well as volunteers from the Linux community.
It probably helps that on Linux, people just got down to work and started fixing things, with the result that OO now tracks native themes in both GNOME and KDE, has a complete native Industrial icon theme (by the same Ximian artists that did the original GTK+/GNOME artwork), integrates with the native file pickers, gnome-vfs, and starts quickly (prelink and the GCC symbol visibility work was motivated largely by OO).
In contrast, whenever OO is mentioned on Slashdot all I see are comments bitching at the developer team and stupid (wrong) statistics being thrown around in an attempt to convince Sun to do the work even though they have no interest or need for it. Because, you know, Mac users are special so they shouldn't need to do the work themselves. The NeoOffice guys are the only ones I know of that are actually getting serious stuff done, and they seem to be years away from getting something that works well.
Although there's no "recommended requirements" section for it, 512 is definitely preferable. OOo X11 itself groans at running in 256, and using native windowing instead requires us to do some backing store tricks because some silly person decided that Quartz shouldn't have XOR drawing. The abstract drawing layer of OOo requires that XOR and isn't designed for any platforms that lack it. ed
believe that TextEdit will open .doc files as it is now.
Yeah, it is built in the OS, and can be enabled for text anywhere. It is still pretty basic (last time I looked). The problem is that there are just too many problems with all the different .doc versions. Apple can certainly make a good run at it, perhaps as good or better than MS, but unlike Windows users, Apple users will have a problem with the bugs in the reader. They are used to things just working and Apple really wants to make products that do that. I fear they will can it before they release something that is not close to perfect. I'm keeping fingers crossed though.
Disclaimer: I am a member of the OOo Mac OS X "team" and a founder of the project.
;)
NeoOffice/J isn't a prototype anymore. It got so good and stable that we decided to make it an official project. We just haven't changed the slogans and copy yet. NeoOffice/J 1.1 is going to be going beta this week, based off of OpenOffice.org 1.1.3 (not even available for Mac OS X X11). It will contain Aqua menus, too.
After we work out all the bugs and get NeoOffice/J 1.1 to final release, we're going to plow ahead with scrollbars and buttons and whathaveyou for a 1.5 release. We'll also be starting on the native work for 2.0 sometime next year, but that will take some effort, considering OOo 2.0 isn't finalized yet.
Our goal is to put out a final NeoOffice/J that is stable, well tested, polished, but most importantly, fully functional. It's generally our opinion that it's more important to be bug-free then pretty. It doesn't matter if it's got pretty blue buttons if it crashes after typing 5 words, and there are definitely testers and users who agree
ed
Read further along for great comments like the disinformation in this which omits our 2.0 plans. There's other ones like this where the project is described as "harmful and destractive" to OpenOffice.org. And this was all in response to a user just saying he enjoyed NeoJ.
If responses like those are not politics and scare tactics, I don't know what is.
(and yes, we do have patches that we've relicensed and submitted that do not get committed back into OOo, such as UTF8 filename support).
ed
Actually, yes... there's that annoying little light bulb.
We had a really pissed employee call the BSA and OSHA.
both of those groups will not leave without issuing a fine, even if you are 100% perfect they will find a way to extort money out of your company.
we would intentionally pull lamps out of an Exit sign, or take one down so that it was easy for OSHA to find a fine for us.
trick for that, NEVER do the same thing twice, they will fine you hard for that.
so if you think you are squeaky clean and looking at a possible BSA audit? set up something cheap for them to find and fine you on... it makes them happy and makes them go away fast.
Do not look at laser with remaining good eye.
Of course that article adresses only legality. For the morality of it, I would say that because we grant copyright to promote innovation and art, we should not protect short phrases in most circumstanses. People offer quips spontaneosly for the approval of the people around them and for their own enjoyment, so protecting them does not promote innovation or art. And the harms of restricting these phrases are great, as every time I want to print something, I need to check if someone else was inspired the same way. This is a far smaller risk for larger works, as the ways of expressing the same idea grow exponentially with the number of words allowed. So while I admire you generosity I think it may be misplaced.
This post written under Gentoo-linux with an SCO IP license.