Linked by Thom Holwerda on Thu 21st Sep 2006 20:12 UTC, submitted by thabrain
Features, Office Based on information discussed at the OOoCON conference in Lyon, OpenOffice starting with version 2.0.4 may include Firefox-like extensions. Also on the board is to incorporate the use of Mozilla Sunbird and Thunderbird into the OOo suite, connectors for Sun Calendaring and Microsoft Exchange support, and even an eventual redesign of OpenOffice 3.0 to run on top of Eclipse, Netbeans or Mozilla's XUL.
Order by: Score:
RE
by Kroc on Thu 21st Sep 2006 22:04 UTC
Kroc
Member since:
2005-11-10

The thing needs a rewrite, not adding more to it >.<
OOo's interface is absolutely horrible. One benefit to moving to a toolkit like XUL would be that the app could be ported to wider systems easier (Firefox even runs on RISC OS), and actually look more native than it currently does! (Firefox is very good in XP, and easy to skin to look native on Mac OS) What hit this would have on speed is yet to be known as XUL is rather sluggish sometimes.

Reply Score: 3

Speed really is an issue
by Hank on Thu 21st Sep 2006 22:42 UTC
Hank
Member since:
2006-02-19

I remember when the first speed benchmarks came out comparing OOo to MS Office it was hard to believe an order of magnitude speed hit was real. I'm here to say it is. I wish it were just a problem where smaller files take a handful of seconds longer, but large files don't see the same ratio of speed hits. I haven't had such luck. In fact, I have a 1 MB Excel sheet that has an equivalent, made from scratch OOo file that is a mere 400 KB. Excel opens the 1MB file in fifteen seconds or so. OpenOffice takes several minutes. I can't tell you how long it takes to import the Excel sheet into OpenOffice because I stopped waiting for it.

OpenOffice developers, I really really really would like you to run it through GlowCode or something and figure out what is going on here. It makes it difficult for me to recommend this as a viable option to people no matter how much I want to.

Reply Score: 2

RE: Speed really is an issue
by hal2k1 on Thu 21st Sep 2006 23:13 UTC in reply to "Speed really is an issue"
hal2k1 Member since:
2005-11-11

//OpenOffice developers, I really really really would like you to run it through GlowCode or something and figure out what is going on here.//

AFAIK there are a couple of issues. The first is that earlier versions of OpenOffice were very slow compared with later versions, so it is really important to state what version of OpenOffice you are talking to.

The second issue is that current Microsoft files formats (ie .doc and .xls) are really just binary dumps to disk of the internal state of the application's memory. To save and load a file, all that Word or Excel have to do is to dump and read (respectively) between the application RAM and the hard disk. For OpenOffice in each direction there needs to be a translation between the file format on disk and the application's memory sate.

Microsoft's binary formats have an inherent speed advantage, but they also have an inherent threat of data loss over time ... they are not "future proof".

If in years to come you cannot run your current version of Word or Excel on your current Windows platform (because the hardware and software has moved on), you run the risk that data you create and save today will no longer be accessible.

Edited 2006-09-21 23:14

Reply Score: 5

RE[2]: Speed really is an issue
by snozzberry on Fri 22nd Sep 2006 00:03 UTC in reply to "RE: Speed really is an issue"
snozzberry Member since:
2005-11-14

I came here to say the exact same thing about binary memory dumps. Word for OS X can no longer read the Word 4.x documents I wrote in college. The Windows version can't read Word 5.x for Mac, and Word 5 was probably the longest-lived version before OS X came out: there were users who uninstalled Word 6 to reinstall 5, Word 6 was so awful.

[before anyone comes in to say it, Office for Windows was quite good at reading parallel versions of the Mac documents]

Live with the fact that very large documents take long to load.

Reply Score: 2

RE[3]: Speed really is an issue
by flywheel on Fri 22nd Sep 2006 04:41 UTC in reply to "RE[2]: Speed really is an issue"
flywheel Member since:
2005-12-28

Also the OO.O developers does not have the full specs on the Windows APIs- which the MS-Office developers do have. This makes it possible for the MS-Office developers, potentially to create more stable, faster and secure applications, than the OO.O developers.

Reply Score: 1

RE[4]: Speed really is an issue
by mormon on Fri 22nd Sep 2006 15:14 UTC in reply to "RE[3]: Speed really is an issue"
mormon Member since:
2005-08-13

You're wrong. There are no hidden functions in Windows that MS Office developers can use. That's a myth for lazy developers. Linux, X has open specification so why OO is even slower than in Windows. Try find somewhere StarOffice 4.0 and run it. It is faster on Linux, Windows, MacOS, OS/2 than MS Office. Sun bougth StarOffice and made it slow and resource hog. That is the truth.

Reply Score: 0

RE[5]: Speed really is an issue
by flywheel on Sat 23rd Sep 2006 01:12 UTC in reply to "RE[4]: Speed really is an issue"
flywheel Member since:
2005-12-28

That is the unfortunate nature of a easy portable framework. XUL got the same disadvantage.
The Stardivision StarOffice was different animals.

Also, if nothing has ever been hidden from the public - why was MS convicted to disclose the specs of 300 APIs and protocols last year in europe ?

Reply Score: 1

RE[5]: Speed really is an issue
by sbergman27 on Sat 23rd Sep 2006 01:21 UTC in reply to "RE[4]: Speed really is an issue"
sbergman27 Member since:
2005-07-24

"""You're wrong. There are no hidden functions in Windows that MS Office developers can use. That's a myth for lazy developers."""

You might want to ask the Wine and Crossover developers about that.

You see, it's pretty obvious when they try to run MS apps against wine's extant API and the app complains about nonexistent calls that are nowhere to be found in the documentation, and which non-MS apps don't use.

This is not some secret that only MS can know for sure. This is quite verifiable by third parties.

Reply Score: 1

RE[2]: Speed really is an issue
by dsmogor on Fri 22nd Sep 2006 18:03 UTC in reply to "RE: Speed really is an issue"
dsmogor Member since:
2005-09-01

Office formats are in no way just memeory dumps.
They are quite elaborate filesystems in image (sort of iso image) that (among others) can be updated in place .

MS uses this container structure all over the place in windows.

The best analogy for them are serialized java objects + some fs stucture.

Reply Score: 1

One word
by shiny on Thu 21st Sep 2006 22:51 UTC
shiny
Member since:
2005-08-09

"and even an eventual redesign of OpenOffice 3.0 to run on top of Eclipse, Netbeans or Mozilla's XUL."


Slow?

Reply Score: 3

Better not use java
by rockmen1 on Fri 22nd Sep 2006 03:01 UTC
rockmen1
Member since:
2006-02-04

Open-Office should focus on performance optimazation as well as functionality.

Reply Score: 5

Hmmmm
by flywheel on Fri 22nd Sep 2006 04:49 UTC
flywheel
Member since:
2005-12-28

They need a more scalable framework, than the current.
XUL sounds like an intrieging suggestion.

I see nothing wrong with the graphical interface - but something is missing, like the use of divisions and an MDI interface. Otherwise something like a new OOO-Base implementation would be great (Perhaps with an MSQL or MySQL/PostSQL engine) and a full support of the Lotus/IBM Smartsuite document-formats.

Reply Score: 2

XUL
by Andre on Fri 22nd Sep 2006 08:32 UTC
Andre
Member since:
2005-07-06

XUL sounds indeed good.
That would bring a great office suite.
to alternative platforms like BeOS and SkyOS.

Reply Score: 1

They'd better fix the REAL deficiencies...
by Temcat on Fri 22nd Sep 2006 08:54 UTC
Temcat
Member since:
2005-10-18

...like the following:

* Lack of drafting mode (known as Normal mode in Word). Print Layout mode is unsuitable when you want to concentrate on the content. In Web Layout mode, you can't see manual page breaks, which is a non-starter.

* Poorly thought out logical model of a paragraph. Try to select a whole paragraph both in Writer and Word and look at the results, then decide for yourself which of them looks sane and which does not. But this is not all: try to select only paragraph text, without the associated paragraph formatting. You just can't do this reliably and predictably in Writer, while in Word it's very easy.

* Bullets and numbering. This is a mess. Besides the format screwup on round-tripping between Word and Writer, the system is just plain hard to use. For example, you cannot quickly and graphically set the distance between the bullet and para text - you have to open the corresponding dialog window and enter a number there. Two-level style system (para styles over list styles) is nice in principle, but cumbersome in practice.

* Tables inside tables. Using text frames for the inner tables is an ugly hack. I need to work with them in Word's Normal mode, too!

* Notes. This part, being essential for the simplest forms of collaboration, is sadly neglected by the devs, though the first issues on that topic have been filed I think around 2001. Non-starter currently: you cannot assign a note to a range of text, it's hard to see because displayed as a tiny yellow bar, and important parts of comment info are lost on import from Word.

Until these issues are fixed, Microsoft has really nothing to fear from the OOo side on the large scale.

Reply Score: 3

jziegler Member since:
2005-07-14

Interesting list. Though I don't remember being pissed off by any of these.

What I do remember is, that MS Office Word always manages to piss me off by screwing up formatting, when joining two paragraphs into one. Getting the result you want strongly depends on deleting the paragraph endings in precise order.. bleah. Applying styles to text selections is black magic too. Mostly it works, but sometimes Word gets stubborn and decides, that it will apply the font/size/color/etc, but the "style" attribute does not change. Or it only applies half of the settings.

This is not to say that Writer is better. This is to say that Word has problems of its own.

Luckily, I'm changing jobs now and hopefully I won't have to work with Word, or anything similar, for a looong time.

Reply Score: 5

Temcat Member since:
2005-10-18

What I do remember is, that MS Office Word always manages to piss me off by screwing up formatting, when joining two paragraphs into one.

That's why I need to be able to reliably select only the text of the paragraph, without the para-specific formatting - then I just copy it to the target para. Unlike Writer, in Word, I can do it with ease. As for joining paragraphs with Del key, AFAIR in Writer it is not easier or more predictable than in Word.

Applying styles to text selections is black magic too.

The key here is the difference between character and paragraph styles. Also you'll want to avoid using non-style formatting as much as possible (though list styles used to give me so much headache that I decided instead to deal with them by copying formatting directly).

To sum up: yes, Word has its own share of drawbaks and plain bugs, but in the end it allows me as a technical translator to get my work done - something I cannot yet say about Writer.

Reply Score: 1

wyth Member since:
2005-12-28

Agreed on the Notes function. I'm currently collaborating on a large document, and the other person uses Word's comments and track changes feature. Everything is clearly marks by balloons that point to the text in question, and outline that text as well. It's quite clear and intuitive. Once the document comes back to me in Word and I open it in OO.o, the comments (now as notes) don't even appear unless I view the non-printing characters, and then I can't manage the notes --can't add, delete, or respond.

So for a few weeks now I've had to go back to Word, after writing over 250 pages originally in OO.o. It's disappointing; it was my first full-on foray into a major project with OO.o, and it just wasn't yet up to the job.

Reply Score: 2

Language
by Andre4s on Fri 22nd Sep 2006 09:19 UTC
Andre4s
Member since:
2006-02-10

What language is OO currently developed in?

Reply Score: 1

RE: Language
by supercharles on Fri 22nd Sep 2006 09:25 UTC in reply to "Language"
supercharles Member since:
2005-08-19

C++. Why?

Reply Score: 1

RE[2]: Language
by Andre4s on Fri 22nd Sep 2006 10:42 UTC in reply to "RE: Language"
Andre4s Member since:
2006-02-10

Just of curiousity

Reply Score: 1

Development
by siki_miki on Fri 22nd Sep 2006 11:43 UTC
siki_miki
Member since:
2006-01-17

I have impression that OO development is stalled. I looked for any devel discussions starting from their web page and found none. Not even any mention of post-2.0.3 versions. Before the 2.0 release there were complaints about lacking manpower behind the project.

Anyhow, Novell recently improved some things in OO and it is present in SLED OO version (new spreadsheet features, VBscrilt support and more accurate font/page/empty space size for imported .doc fles). Will this work be integrated back into OO?

Moving to XUL sounds like a sane idea, it is a tried, mantained platform (Firefox & extensions) and higly portable, allowing also good module/extension support, which could be a killer feature for an office suite.

OO needs a huge refactoring process to be taken, anyway.

Reply Score: 1

RE: Development
by Temcat on Fri 22nd Sep 2006 12:58 UTC in reply to "Development"
Temcat Member since:
2005-10-18

Moving to XUL sounds like a sane idea

How so? It'll only make OOo even slower than it is now :-(

Reply Score: 1

RE[2]: Development
by brown_rm on Fri 22nd Sep 2006 16:20 UTC in reply to "RE: Development"
brown_rm Member since:
2006-02-23

Moving to XUL sounds like a sane idea

How so? It'll only make OOo even slower than it is now :-(


Would it? OOo currently uses its own cross-platform toolkit, right? So it isn't like we are comparing a native Gnome, KDE, or Windows app to an XUL app. I honestly don't know if XUL or OOo's toolkit is faster. Though not native speed, Firefox doesn't seem that slow to me. Also, there is some benefit to having OOo using the same GUI toolkit as Firefox, Firebird, and Sunbird (resources spread over fewer projects, toolkit knowledge applicable to multiple projects).

Reply Score: 1

OOoCon VIDEOS!!!
by uros on Fri 22nd Sep 2006 14:53 UTC
uros
Member since:
2005-09-28

For those who were not able to attend the conference Cyberpipe Media Team was there once again and provided video streams and archive for all of you! These guys are doing an excellent job!

You can get the videos at: http://ooocon.kiberpipa.org/

Reply Score: 1

jrlah
Member since:
2005-08-09

...is the biggest thing that stops OpenOffice adoption in the academic world. Endnote-like functionality is absolutely essential for our day-to-day work. Current bibliography features in OOo are useles in that respect, and the bibliographic.openoffice.org project is mostly vaporvare for now.

Reply Score: 1

port to a decent toolkit
by superstoned on Tue 26th Sep 2006 11:34 UTC
superstoned
Member since:
2005-07-07

they should port OO.o to a decent toolkit (like Qt) so it'll be much easier to maintain, faster and smaller...

or just quit it, and start developing on Koffice - after all, if they spend a year on that, it'll have surpassed OO.o like it would be in 10 years ;)

Reply Score: 1