LibreOffice 4 Released 249
Titus Andronicus writes "LibreOffice 4.0.0 has been released. Some of the changes are for developers: an improved API, a new graphics stack, migrating German code comments to English, and moving from Apache 2.0 to LGPLv3 & MPLv2. Some user-facing changes are: better interoperability with other software, some functional & UI improvements, and some performance gains."
Re:But what if Java is the next WAIS? (Score:5, Informative)
OpenOffice/LibreOffice is like 90+% C++. The Java bits are mostly irrelevant.
Pre-fork OO (Score:3, Informative)
I have been using the last pre-fork version of OO. It works fine and mostly does what I want.
Is there any good reason to switch to the latest Libre?
Re:But what if Java is the next WAIS? (Score:5, Informative)
Re:But what if Java is the next WAIS? (Score:5, Informative)
Re:But what if Java is the next WAIS? (Score:5, Informative)
And you do not need the JRE to run LibreOffice.
Re:Why this dilution? (Score:5, Informative)
Oracle tossed OpenOffice to the Apache Foundation after LibreOffice took-off in terms of features, bugfixes and mind-share.
OpenOffice is about 2 years behind thanks to Oracle.
Re:Damn! (Score:5, Informative)
Re:MS Office mewlers and shills, queue here! (Score:5, Informative)
That started happening as soon as they forked.
Sun made it really hard to get some changes made upstream, and some developers were unwilling to hand over copyright on their code contributions. So OpenOffice stagnated for many years.
There was a cleaner, more feature-rich version called go-oo (which many Linux distros shipped, without really telling anyone they were getting the fork). That fork because the basis of LibreOffice. Once they weren't tied to staying close to the OpenOffice base, they started cleaning cruft like mad.
In case you didn't notice, they added a bunch of new features, while the size of the installer dropped from 200 MB to 183 MB in this latest release.
Re:Why this dilution? (Score:4, Informative)
I am a Java developer, love the JVM, but if you think merging the Lotus Symphony code base with OpenOffice will be a good thing, you never used Symphony. Symphony is the Eclipse platform with added plug-ins that add old OpenOffice code to it. If an office suite is already a big program, running a big JVM process with OpenOffice inside is an awful monster. In the other hand LibreOffice is removing Java dependencies where it shouldn't be used, like the embedded database and some wizards and using it for what is a good tool, Java APIs for automation and access to core LibreOffice functionality from Java programs
Re:But what if Java is the next WAIS? (Score:5, Informative)
OpenOffice/LibreOffice is like 90+% C++. The Java bits are mostly irrelevant.
To be precise, as computed by sloccount [dwheeler.com], libreoffice-4.0.0.3.tar.xz contains:
cpp: 3990644 (87.04%)
java: 400958 (8.75%)
ansic: 91036 (1.99%)
perl: 42456 (0.93%)
python: 17392 (0.38%)
sh: 17256 (0.38%)
yacc: 8228 (0.18%)
cs: 6648 (0.15%)
asm: 3269 (0.07%)
objc: 2602 (0.06%)
lex: 2030 (0.04%)
awk: 907 (0.02%)
pascal: 800 (0.02%)
csh: 235 (0.01%)
lisp: 115 (0.00%)
php: 104 (0.00%)
sed: 7 (0.00%)
However, as Desler said, the Java bits are actually optional.
Re:MS Office mewlers and shills, queue here! (Score:1, Informative)
It's a good helper for old MS Office files when MS Office itself chokes on it. But if your daily work involves exchanging current MS Office files with co-workers and customers, with all involved parties editing the documents, you absolutely have neither time nor will to constantly deal with even minor issues. And like it or not, that's the reality for a lot of office workers.
Re:"migrating German code comments to English" (Score:2, Informative)
posting AC since I don't have a /. account.
in fact, not "code-comments" in LibreOffice were german. Rather it were "germanisms" in the code itself. I can't remember specifics ATM, but it was naming of variables and functions that "looked akward" to native english speakers.
I'm not aiming for informative modpoints, although appreciated :)
I know the specifics because I speak english & german and considered attacking this bug 1-2 semesters ago.
Re: "migrating German code comments to English" (Score:2, Informative)
As someone who did a lot of those translations I may be able to explain the necessity for these:
First, LO's source code is old and massive. Most of the comments I translated were written somewhere in between 1999 and 2004.
Second, as anyone who has ever dealt with old, mature, complex code bases will tell you: you need as much information as possible about your code. This is due to bug fixes and quirks that evolved that code over time (=maturing a code base).
Of course, many of the comments are simple and obvious, but there's always the suspicion that some of them contain crucial information. This is exactly the reason why we're not using software translation programmes (e.g. Google Translate), but rather translate all comments by ourselves.
Finally, please note that the remark about translated comments is not meant as a feature advertisement for end-users, but as a public sign of gratification for those many volunteers that put much of their free time into doing them.
Re:MS Office mewlers and shills, queue here! (Score:5, Informative)
You may not be aware, but that is correct behavior.
A PPT file is meant to open in edit mode. A PPS file is meant to auto-play a presentation when opened.
If you don't want it to auto-play, then blame the person who saved the file as a PPS file.
Re:"migrating German code comments to English" (Score:5, Informative)
Then again, English is a pretty strange Indo-European language. It has a lot of complexity where it doesn't really add anything, like the plethora of irregular verbs, or the many words that end with the letter e for historical reasons, despite it not being pronounced for centuries. And in other areas, the simpler rules of English come at the cost of expressive ability. Almost non-existent verb conjugation makes things simple, but it also requires 3 words to say "we will run" as opposed to a heavily conjugated verb like "correremos".
Compulsive linguistic fetishist chiming in here:
The "irregular verbs" are not irregular in English (at least, not if you're referring to the stem changers; there are some true irregulars but not many). Swim-swam-swum, sing-sang-sung, etc. (and several other varieties of stem-changers) are ALL regular. They were mislabeled as irregular by 19th century prescriptivist grammarians who didn't know what they're talking about (and who thought that Latin was "perfect" and that any deviation from Latin represented grammatical corruption). The "irregular" verbs are Anglo-Saxon strong verbs. They follow clear, regular patterns and pre-date the influence of Norman French.
Spelling peculiarities are a product of the (relative) freezing of orthography with the invention of the printing press. This is not a linguistic issue, it's one of editorial culture. We COULD have changed spellings as pronunciations changed (and other Indo-European cultures did change their orthography as pronunciation changed in the centuries since the invention of the printing press), but for political reasons have not. It has nothing to do with the language itself (other than the fact that freezing orthography tends to retard language change).
Verb conjugation was not nonexistent in Anglo-saxon words (your "irregular verbs"), and its slow disappearance is the result of Norman influence. Conjugation in Anglo-Saxon was a stem-change, not an inflection. Initially, the only nonconjugating words were borrowed from Latin and Norman French. Over time, because of the prestige status of Norman French, those words became the new normal in English, and old strong verbs begun to lose their conjugations. As an example, it used to be Climb-clamb-clumb, not Climb-climbed-climbed.
Your "we will run" vs "correremos" point about the Spanish being shorter is silly. The English version is 3 syllables and the Spanish is 4. So which is actually shorter to say?
English is weird for an Indo-European language because it is actually a hybrid of the Germanic and Romance branches. This hybridization stripped out incompatible features between the two source families.