OpenOffice.org Built with KDE and GNOME Support

ks writes "Novell hacker Jan Holesovsky has released a build of OOo 1.1.3 that integrates with either KDE or GNOME depending on the environment it's running in. The build features KDE/GNOME look and feel, KDE/GNOME file dialogs and the Crystal icons. If you're running NLD, you have this already." Update: 11/27 18:13 GMT by T : Also on the OpenOffice.org front, the OO.o front page links to this interview with Debian ARM developer Peter Naulls, who has ported the suite to ARM processors. Hint: they're everywhere.

Re:I've seen it in action, it's pretty sweet

[rppp01]

I am actually going to be doing a presentation on how you can use linux as a workstation/desktop in a work environment. I am choosing OOffice as the office suite. I am glad to see it integrates with both environments.

How does it support things like ppt, doc and xls files? I really wanna impress who I am showing this to.

n-tierety

[Doc Ruby]

This is a great move, generating momentum towards a real superior Linux desktop architecture. Any well designed app should be split into Data, Business and Presentation layers, independent/interdependent of one another across a clear, well defined API. This new build can be optimized by another programmer to actually separate the Business (OO.o) and Presentation (KDE/GNOME) layers, because the source is open. Refactor OO.o as an object that can run separate from its UI, and all its features are available to *any* calling program, reusable without having to write spellcheckers again, or text edit panels, or .DOC readers. In fact, the next great move will be to refactor the OO.o data layer, so it can run not only on any FS, like ext3, ReiserFS, SMB, NFS, but interchangeably across networks as straight sockets, or SQL DB tables, or RDF streams, or any data source that's adapted to the data API. Let's get it on!

Does anyone know

[Anonymous Coward]

Does anyone know if this is going to be integrated back into the OOo trunk?

Running NLD

[owlstead]

What if I'm running it _in_ NLD? 'Cause I'm there already.

This is a good thing. One of the reasons that Java never took off from the desktop was that it didn't integrate with the native GUI. Nice to see OpenOffice not making the same mistake.

Too many linux applications still have horrible, unusable file selectors. It will never take off as long as such monstrosities are present everywhere.

This is one of the reasons why Windows is used by so many people. They do provide a more or less monotone interface. Even if the interface is horrible (like personalized menu's) it's horrible all over the place.

Re:First Reply|

[mini me]

Seems like a convoluted solution, but it really works quite well.

In fact, on my machine at least, the Qt GTK+ theme is faster than the native GTK+ themes. The only problem is that it's still a bit buggy.

Aqua on Mac OS X

[HeelToe]

Oh please, let's do this for Mac OS X!

Re:n-tierety

[Doc Ruby]

You don't like applications to have 3-tier architecture with IPC APIs? You must have been burned pretty bad - maybe you even worked at Taligent while I was over at Apple. After we switched the APW to C++, we all thought we'd never rewrite "EditableTextPane" again. But we were naive enough about sharing source with strangers that we didn't realize that once the source is open to the public, we need it to come with human-readable docs to reuse it. That's why the API is so important. As are practical conventions, like the 3 tiers, rather than a freeform n-tier model where the APIs are never split consistently enough to fit together completely. Especially with web services and OO.o, we've got another chance to do this extremely important pattern right, or screw ourselves again for yet another decade.

Here's what I want!

[erroneus]

FC2/FC3 RPM packages.

That's all. On one hand, I like the way RPM works and what it does for the user. On the other hand, I can never seem to get the most up-to-date packages. It's terribly unfortunate and is always a balancing act between installing from tarball and maintaining RPM integrity. I suspect there are ways of handling it better and further that someone might even volunteer these better ways right here in response to this.

But if someone out there loves to build useful RPMs and has already built RPMS suitable for FC2 and/or FC3, please let me know where they are! I know I can't be the only one wanting them.

What about OS X?

[ciurana]

Disclaimer: I'm an OOo advocate, as you can see from this Computerworld article (http://www.computerworld.com/softwaretopics/softw are/apps/story/0,10801,92195,00.html?SKC=software- 92195 [computerworld.com]) that I published last Spring.

I used OOo since the days of StarOffice. I managed to write two books, many presentations, spreadsheets, and countless business documents in it. OOo is probably one of the best office applications and it's cross-platform.

I had quasi undying loyalty to OOo until I decided to go to OS X. While the feature set is almost identical to other versions of OOo, the GUI is one of the ugliest. OOo also lacks compatibility with Exchange servers, which I'm forced to use for work (yuck!). For these two reasons, I had to cave in and return to Office:Mac.

The efforts to tightly couple OOo with KDE or Gnome are important and interesting but far from the marketing win that OOo needs. An OOo version that supports the native OS X look and feel would probably win lots of support from Apple's user base because it would be, in most cases, a drop-in, free replacement for Office:Mac.

I interact now with quite a few Mac users on regular basis; most, if not all, would love to ditch Office:Mac in favour of OOo if the GUI and other system integration issues were resolved. I believe that an OS X/Aqua version of OOo is more strategically important than one for Gnome or KDE because it would generate instant press outside the early-adopter, Linux world.

A strategic marketing win could result in additional funding/participation/donations to OOo to carry on with other projects that, although important, lack the visibility that the Mac has or could bring to OOo.

Cheers,

Eugene

Re:n-tierety

[m50d]

Well, KDE integration is less important, since KDE has a proper office suite of its own. As far as I can see, "gnome office" consists of Abiword and Gnumeric pretending they're an office suite.

Re:Still not native GNOME or KDE

[cmbofh]

Let me add:
If you really want a native office suite then I think that KDE + KOffice is the most integrated, complete and promising for the future. Although I think it's not there yet, especially the MS format filters of OOo are still more usable in the real world (and no, using the OOo filters in KOffice is not an option, that has been discussed over and over again).

Re:I've seen it in action, it's pretty sweet

[cecil_turtle]

I've completely switched to OOo at home and haven't had any real problems, and use it a lot at work in conjunction with OOo.

My most complex Excel sheet converted easily and I only had to change of couple of functions where the OOo arguments were slightly different than Excel's. Also the file size in that particular Excel document was over 2MB but the OOo native file size was 94k (they use an XML format and then zip compress it - that's why some people claim OOo to be "slower").

I didn't even think about PPT's until I needed to open one on my laptop for a presentation. To my suprise it opened right up in OOo and I played the slideshow with no trouble.

Another thing to consider is that OOo can natively save PDF documents from any spreadsheet or document.

The issue with macros has been blown a bit out of proportion with some of the above posts. It is true that MS Office is very powerful with scripting, but honestly it's more of a small business solution to do some basic automation cheaply. Mid and large size companies typically have dedicated systems to perform such tasks / calculations. As far as interoperability with other companies, I haven't seen any kind of complexity in an Office document that came from another company as a public document that would cause any kind of issue with OOo.

To address the user issue, most secretaries and PHB's don't know MS Office well enough to even notice a difference. OOo has the same formatting toolbars that do the same thing. For the MS Office "experts", they should be savvy enough to learn OOo.

All of that said, please do be sure to spend the time and learn it yourself before you do the presentation on it.

Re:My my my...

[mfg]

You can do exactly what the author is describing in Microsoft Word, and it is a hell of a lot easier than Tex. As you are typing your document, you simply mark things with Heading 1, etc (create new styles as you need them). When you're done "composing", then edit the styles such that your document is rendered as you want it to be.

One of the nice things about a markup language compared to a word processor is that the document style is under the control of the user - the person who'll be reading the document - rather than the author. If you want full control over how a document looks then ship it as PostScript or PDF.

Another useful thing about markup languages is that they're usually plain text, which makes them readable even if you don't have a particular program. This also makes them easy to process automatically - extracting the title, authors, abstract etc. for example. Given a repository of papers, we can automatically produce statistics showing, for example, how many papers each author has published - just the sort of thing that funding bodies want to know. Try doing that with some WYSIWYG format where the various sections are obvious to a human eye but don't have anything in the file to say that centered text in bold is the title, the first italic bit is the abstract etc.