KDE integrates OpenOffice.org

In this interview, Jan Holesovsky, author and leader of the
KDE.OpenOffice.org project, now employed by SUSE, gives us a glimpse of what to expect in terms of OpenOffice.org integration
on your KDE desktop. The future sure looks bright!



Please give us some background information about yourself.

I am 27 years old, living in Prague, the Czech Republic, graduated from
Charles University,
also in Prague.

When not sitting in front of the computer keyboard, I am usually in hills or
mountains with my friends---trekking, climbing, mountain biking or
cross-country skiing depending on the season.

What's the focus of this project and how did it start?

It began in July 2003 when I read an article
about Ximian's work on
improving OpenOffice.org. There was also a note about a (now unmaintained)
Bonobo OOo integration project, and I was wondering, whether anybody
had started a similar project for KDE.

I had just graduated, and I wanted to travel in October, so instead of
searching for a job I was reading the OOo documentation and programming
cuckooo . The initial version
was available in the middle of August, so I still had some time left before
the travelling. I started the "OpenOffice.org Qt port",
now "KDE vclplug", because I wanted to replace all the OOo GUI toolkit "VCL" with its Qt implementation. I
finished a proof of concept a few days before I left. When I returned, I wanted
to continue my OOo work as an employee.

I started KDE NWF in December when
I saw the big demand
for OOo Native Widget Framework

on [email protected].

How many people are working on this?

Currently, I am the only developer. Lukas Tinkl sent me a patch to NWF that
corrected behavior of combo boxes and introduced tab bars.

Are you paid to work on this project?

The search for work resulted in a contract with SUSE.
I became their employee the last week, and now I am paid to continue the KDE OpenOffice.org
integration. Here I want to thank Holger Schroeder once more. He donated the money that
covered the first part of my Native Widget Framework development.
All the work on cuckooo and KDE vclplug (OOo Qt port) I did as a volunteer.

Is there a website? Is there a CVS repository somewhere?

kde.openoffice.org is the main page of the integration
project. It is an official OOo "Incubator" project,
so it has all the possible support from the OpenOffice.org side.

There is no separate CVS repository for the project. KDE Native Widget
Framework is already in the OOo CVS repository
(branch cws_srx645_nativewidget1);
KDE vclplug (OpenOffice.org Qt port) will hopefully appear in the OOo CVS
repository as well.

When looking at the website it seems that there are 3 subprojects:
Cuckoo,
OpenOffice.org Qt port
and KDE NWF.
Can you describe the technical differences between the three projects
that are part of kde.openoffice.org



The idea of cuckooo is to use the UNO API
of the OpenOffice.org to access its
functionality from Konqueror so that people could
browse to MS Office documents which would
open directly in the browser's
window
. Cuckooo itself is a KPart which controls an instance of OpenOffice.org
running in the background and displaying to the KPart's window.

KDE vclplug, formerly known as OOo Qt port, has the goal to get OOo controlled by Qt events and drawn by Qt
painting methods instead of pure X calls. It is developed for
OOo 2.0 and it is still
quite experimental stuff. It does not support KDE styles, but once the
Qt events are working, it will be possible to use standard KDE dialogs (e.g.
the file dialog).

OOo NWF uses the Native Widget Framework
to provide OOo with the
look
of
the
theme
that the user chose for his KDE desktop. The framework uses the QStyle API to draw its widgets the same way
KDE/Qt would. OOo with NWF does not have a Qt event loop. It is developed for
OOo 1.1, but it will be used in 2.0 as well; then it becomes part of the KDE
vclplug subproject.

Is there any other work being done besides these three subprojects?

You might be interested in
"OpenOffice.org
1.1 toolbar icon themes
",
a script and a set of KDE icons
for OpenOffice.org by Rohit Kaul. There is also "OOo kfile-plugin"
by Pierre Souchay (screenshots 1,
2,
3).

What is the current state of KDE integration?

The current version of cuckooo (0.3) seems to be stable and I am not going to add
new functionality in the near future. KDE NWF is nearing completion. I expect a fully usable version in February.
KDE vclplug is a long term solution, but it will take quite a lot of time to
finish. I would like it to be a part of OOo 2.0 which is estimated in Q4 of
2004 or in the beginning of 2005.

Does it seem feasible to ditch the abstract GUI of OOo and work directly
with Qt?

No, OOo will still have to have its own GUI layer. However there are plans to
define a more abstract OOo GUI toolkit "Toolkit2"
based on UNO calls. Services of "Toolkit2" would be implemented in toolkit which is native
for given platform (e.g. Qt for KDE). Unfortunately, due to the complexity of
the rewrite it is planned as an "after 2.0" work.
See these two
messages for more information.

Will "integration" include support for important low level KDE features like
the Kiosk framework sometime?

First of all, the KDE NWF and KDE vclplug have to be stabilized. Then I can
integrate KIO and KDE dialogs to OOo and continue with further efforts, be it
KParts, Kiosk or other KDE features. I am afraid it won't happen before 2005.

Will there be a KDE "version" of OOo in such that it looks and ACTS like a
KDE app?

That is my intention. :) But it will take a lot of time. NWF is the first
iteration, and vclplug will help; Toolkit2 is hopefully the definitive
solution.

A lot of people that have looked into developing OpenOffice.org found it very complicated,
what is your experience?

It is really a huge amount of code. Luckily it is quite well modulized, so
once you get used to it, you do not encounter big problems. And if you do, you
still have OpenOffice.org Cross-Reference handy.
If you want to know more about OOo development, try
CPH's excellent CVS digest,
mainly the first one with the introduction.

How is it to work with OpenOffice.org people? Does Sun have a big influence
over the development?

I like the way the OOo people cooperate very much. They are very supportive
and every volunteer is welcome. KDE.OpenOffice.org couldn't have happened without
the support from the OOo side. I can't really say anything about Sun's influence over the development,
as my only contact with Sun on an official level was when I signed the
JCA
(a copyright assignment system).

Where do you see KDE.OpenOffice.org going and what are your plans for it?

The mission statement of KDE.OpenOffice.org says "The goal is to provide tight
(but optional) integration of the OpenOffice.org to the KDE environment
beginning with KDE look and feel and ending with KDE data sources." I believe it can be achieved.

What is the project most in need of now?

Time. It is the only limiting factor at the moment. :)

Dot Categories: 

Comments

by aleXXX (not verified)

On linux we already have some kind of kde ioslave integration into OOo (opening remote files via kioslaves from konqueror in OOo). Saving works also.
I'd consider it beta quality:

http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway

Bye
Alex

by aleXXX (not verified)

I forgot to mention:

IMO good KDE integration of OOo is one of the most important projects for the future of KDE.
Very cool work ! :-)

And thanks to SUSE !

Bye
Alex

by jo (not verified)

hmm yes, i'm very happy to hear that they employed him 1 week before. it seems like they still support kde - even if novell already owns ximian ...

by Asdex (not verified)

> even if novell already owns ximian

Ximian is going to develop for KDE.

by Anonymous (not verified)

Reference for this claim?

by another ac (not verified)

I'm pretty sure it was a joke..

by jmk (not verified)

http://news.com.com/2100-7344_3-5151359.html?tag=nefd_top

If ximian is now being split up and Richard is put in charge, who knows what will happen..

by another ac (not verified)

wow, three articles, all today :) (I guess i'll have to take that "it's a joke" comment back)

FWIW, there were some articles saying nat & miguel were taking over desktop stuff at novell - but i think this trumps them. Either way, it's gonna make a nice flame-fest over at slashdot when it hits ;)

by Asdex (not verified)

Maybe, but Markus Rex from Suse now is head of Novell's Linux-Desktop activities.
http://www.heise.de/newsticker/meldung/44246

by Anonymous (not verified)

Miguel and Nat are not anymore in charge of it? :-)

by tackat (not verified)

Just from http://www.suse.de/en/company/press/press_releases/archive04/suse_bu.html

"Rex, previously SUSE's vice president, Research and Development, will assume his new duties immediately. As general manager of the SUSE LINUX business unit, reporting to Chris Stone, Novell vice chairman - Office of the CEO, Rex will lead the development of SUSE LINUX, from the DESKTOP to SERVER, and will work with other Novell business units to deliver a complete Linux solution stack. Rex will also assume responsibility for Novell's Linux DESKTOP activities."

Well, usually I trust information that comes from the source more than some people who need to comment on slashdot just to gain attention, so ... ;-)

Tackat

by Roberto Alsina (not verified)

The news.com.com.com.com article said Markus Rex was becoming general manager of Novell Europe?

by Anonymous (not verified)

This seems to be wrong, he gets General Manager of Novell's SUSE LINUX Business Unit: http://www.suse.com/us/company/press/press_releases/archive04/suse_bu.html

by OI (not verified)

Well, actually it makes sense.

With the Qt-Gtk style and the possibility to use KDE file dialogs in Gtk apps, is is in fact now possible to make KDE-apps, in Gtk. Weird, huh?. This is because they will look (and probably soon feel) like any other KDE-app.

Basically, if you're on KDE, you have the option of developing in either toolkit. More options for you in many aspects. Why choose less options?

Am I wrong?

by ac (not verified)

"First of all, the KDE NWF and KDE vclplug have to be stabilized. Then I can integrate KIO and KDE dialogs to OOo and continue with further efforts, be it KParts, Kiosk or other KDE features. I am afraid it won't happen before 2005."

What value does KOffice offer over such an ambitious and extensive hack?

by Birdy (not verified)

Speed, usability(?), better frame-support (kword), and more little details...

by ealm (not verified)

"What value does KOffice offer over such an ambitious and extensive hack?"

The day OOo integrates with KDE (almost) as good as KOffice, KOffice might be (almost) as usable features-wise. So the answer is about the same as to why we need khtml when we got gecko already. With KOffice vs OOo the situation is somewhat the same as with Gecko vs khtml - one featureful, but big and non-initiutive solution, and one not as featureful, but better integrated and lighter. If you can go with the second, it will probably do better.

by cies (not verified)

Just donwload 'm both (KO 1.3 and OOo 1.1) and compare...

by Aaron J. Seigo (not verified)

Besides speed, lower resource usage, cool features (like KWord's frames) and native KDE integration, KOffice has Kivio, Kugar and Kexi. Greater use of components (e.g. kchart and kformula) and libraries encourages third party development; I've already seen a few KOffice-based apps out there and expect to see more in the future. And if/when KPlato, Krita and Karbon get to production quality, we can add a few more things to the pile.

by Arend jr. (not verified)

Personally, I see it the other way around. As soon as KOffice supports the OpenOffice.org file formats and its good filters, what value does OOo offer over KOffice anymore?

by Eric Laffoon (not verified)

Aside from all the other good answers here... OOo offers solid basic applications primarily focused on word processing and spreadsheets with secondary apps in presentation, drawing and from there it's less worth mentioning. It's good for migrating from MS Office. On the down side, even when it integrates with KDE it's still cumbersome, slow and a lot more than people need. Also it doesn't have some of the other apps mentioned. Fortunately we won't have to select one or the other because we will be able to choose based on our personal taste and the task at hand.

If you want to ask where the future lies though Koffice has huge potential. It's small, fast, light and innovative. It's hard to say what the future holds but Koffice is compelling. With a KDE OOo and Koffice we would be able to offer something there is all to little of on the office landscape today... solid choices.

by alek (not verified)

I just hope that all of this debate ends up with applications that integrate well together.

I'm talking about copying and pasting a Kivio diagram seamlessly into an Impress presentation... You know a bit like Windows - dare I say without being shot.

I believe the K suite offers some excellent apps, but I believe OOo is going to be the mainstream wordprocessor, spreadsheet and presentation tool, specifically in large installations in government and corporations -- not least of all due to those organisation's Microsoft Office legacy -- and the huge punt to support OOo by the likes of Sun, IBM and Novell.

As such the K apps need to work well with OOo to gain broad acceptance from lesser mortals (ie. those who don't read news on the kde.org site ;-)

My two cents worth anyway...

by gerd (not verified)

But eric, the left toolbar is very confusing

by standsolid (not verified)

This project looks really, really nice. I'm thrilled that Jan was hired by SuSE and is still able to work on this project.
I'm so very excited for this release and can't wait to test and report bugs once it's ready :)

And thanks a bunch for the interview Fab!

//standsolid//

by Fabrice Mous (not verified)

thanks Kenny

Ciao

Fab

by Jadrian (not verified)

Since we're talking about KDE/OOo integration I thought I'd let you know abuot this OOo bug I reported that affects KDE users.

"DnD pictures from Konqueror to OODraw problem."
http://www.openoffice.org/issues/show_bug.cgi?id=23526

Should this kind of thing be reported to the KDE.OpenOffice.org project?
I know it doesn't really fit any of the projects, but on the other hand, people with experience in both KDE and OOo may be a good help in its resolution, and it does have an impact in OOo usability under KDE.

J.A.

by Jan Holesovsky (not verified)

No, this kind of bugs should be reported to the respective OOo components, e.g. component "Drawing" in this case (it is correct in your bug report :) ). But if you encounter for example a button misbehaviour when using KDE NWF, then report it to the "KDE" component.

Jan

by Jadrian (not verified)

Ok, thanks!

by Nick Shafff (not verified)
by bleb (not verified)

>> All big projects are going to use qt
>>
>> ftp://blah...

Don't talk shit please.

The date of that file is 20-10-1998.
Mozilla is not going to use Qt.

by KaiRo (not verified)

> The date of that file is 20-10-1998.

True, it's been a long time since someone worked on Mozilla Qt support, it has even been removed from trunk CVS as it was unmaintained.

> Mozilla is not going to use Qt.

That's not said. It's true that currently there's no support, but it can be re-established any time if someone does work on it.
Mozilla has good ability to use different toolkits (currently Xlib, GTK+ and GTK+2 are supported and in CVS, GTK+ being the default used one), and there's nothing against adding Qt to that (as long as the port is maintained). We (the Mozilla community) would be very glad to see better KDE integration, so if someone is out there and wants to help, it's appreciated (I don't want to discourage you to help on OOo intergration though ;-). Look into http://bugzilla.mozilla.org/show_bug.cgi?id=140751 (+dependencies) and the netscape.public.mozilla.at newsgroup as staring points.

It would be really nice to see much better integration of major apps as OOo and Mozilla and KDE (besides having e.g. KOffice and Konqui browser as well). The Open Source communites are great, let's make them really come together!

by KaiRo (not verified)

er, sorry, the newgroup name ends in .qt, not .at, of course

by Nick Shafff (not verified)

anyhow, i'm not going to use mozilla untill
http://bugzilla.mozilla.org/show_bug.cgi?id=105843
get fixed

by geert (not verified)

Will it be possible to run Kopenoffice through KDE instead of X11 on Mac?

by foo (not verified)

Probably, with some work, since complicated KDE apps already work with the native OS X Qt. It would be amusing if the KDE port of OOo finished before the native OS X port did.

In general, Qt on OS X needs a lot of work though, and apps produced with it look and feel really ugly and non-native. As I was looking at some of the OOo screenshots I realized that there were many GUI 'mistakes' in them, but I'm just not trained to look at tiny pixel errors in KDE apps. Whereas when Safari 1.2 makes the search field two pixels taller and insets the search text a bit, I can tell immediately. I guess the Mac just tends to inspire that kind of attention to detail, in me at least.

by Anonymous (not verified)

> Qt on OS X needs a lot of work though, and apps produced with it look and feel really ugly and non-native.

Did you try Qt 3.3 Beta 1? From its changelog: "Numerous visual improvements."

by Don (not verified)

> In general, Qt on OS X needs a lot of work though, and apps
> produced with it look and feel really ugly and non-native

I'm aware of two 'look' problems with Qt on OS X, one is the pulsing color of Qt/Mac default buttons is slightly different from other OS X apps. The other is that Panther style tabs aren't supported, (this is an appearance manager limitation other applications are affected by it also).

If you can provide specific look criticisms (screenshots could help) then I'm interested.

In general Qt doesn't draw widgets on the Mac, instead it delegates this responsibility to OS X via the Appearance Manager API. This API has the limitations mentioned above.

Please note that Qt/Mac applications ported from other OS' won't always look native, they might use Windows toolbar icons, fixed layouts with spacing and placement inconsistent with the Aqua style guidelines, etc.

Don
KDE Software Engineer,
Qt/Mac Software Engineer,
etc.

by anon (not verified)

> If you can provide specific look criticisms (screenshots could help) then I'm interested.

forgive me if any of these are kde or apps bugs...

- the toolbar dragger should not appear on OSX.. usually toolbars can be moved throughb context menus (in KDE as well)

the toolbar button seperators don't look right on http://ranger.befunk.com/screenshots/qt-mac-apps/flashkard.png .. see http://ranger.befunk.com/screenshots/qt-mac-apps/kfind.png how Terminal.app does it..

- the Splitters aren't drawn OSX-y..

http://ranger.befunk.com/screenshots/qt-mac-apps/kdict.png
versus http://www.cocoatech.com/images/demo/customize.jpg

- tab text not aligned well

http://ranger.befunk.com/screenshots/qt-mac-apps/kcontrol.png

- combo text not aligned well

http://ranger.befunk.com/screenshots/qt-mac-apps/klettres.png

- kmines bug?

http://ranger.befunk.com/screenshots/qt-mac-apps/kmines.png

- the statusbar frame collides with the dragger... kstatusbar bug?

http://ranger.befunk.com/screenshots/qt-mac-apps/kjumpingcube.png

- more text alignment problems.. this time in listview

http://ranger.befunk.com/screenshots/qt-mac-apps/kmail.png

- tab needs to be moved up one or two pixels imho.. or blended in

http://ranger.befunk.com/screenshots/qt-mac-apps/kopete.png

- text not clipped in combo?

http://ranger.befunk.com/screenshots/qt-mac-apps/kbruch.png

- konsole tabbar bug?

http://ranger.befunk.com/screenshots/qt-mac-apps/konsole.png

- khexedit find button bug

http://ranger.befunk.com/screenshots/qt-mac-apps/khexedit.png

- calander navigation buttons not centererd

http://ranger.befunk.com/screenshots/qt-mac-apps/korganizer.png

- bottom line edit not panther like

http://ranger.befunk.com/screenshots/qt-mac-apps/kcharselect.png

- stripes not panther like

http://ranger.befunk.com/screenshots/qt-mac-apps/kbruch.png

by Don (not verified)

Thanks, for the more detailed level of feedback.

> - the toolbar dragger should not appear on OSX.. usually toolbars can be
> moved throughb context menus (in KDE as well)
...
> the toolbar button seperators don't look right on
> http://ranger.befunk.com/screenshots/qt-mac-apps/flashkard.png .. see
> http://ranger.befunk.com/screenshots/qt-mac-apps/kfind.png how Terminal.app
> does it..

I don't think there is a single standard look for toolbars on OS X. Different Apple applications choose different toolbar styles, and third party Apps use different looks again. I don't think the Terminal.app style toolbar is appropriate for KDE apps on OS X, I think a TextEdit.app style toolbar, with smaller toolbar widgets, is more appropriate for a KDE ToolBar style for OS X.

But yes I can't see any OS X app with a toolbar dragger, that could go. The toolbar button separators I think may be part of the appearance of KToolBar rather than QToolBar. In which case fixing that would require a KDE style rather than Qt style change.

> - the Splitters aren't drawn OSX-y..

Looks valid.

> http://ranger.befunk.com/screenshots/qt-mac-apps/kdict.png
> versus http://www.cocoatech.com/images/demo/customize.jpg
>

Unfortunately I don't follow here.

> - tab text not aligned well
>
> http://ranger.befunk.com/screenshots/qt-mac-apps/kcontrol.png
>
> - combo text not aligned well
>
> http://ranger.befunk.com/screenshots/qt-mac-apps/klettres.png

Yes, I see several of the issues you've mentioned are of a text not aligned well nature. Further investigation is required to determine if these are KDE, Application or Qt problems. Sam might be a better judge but personally I can't tell without investigating these issues on a case by case basis. Each case like this has to be examined to see if it can be reproduced in a small Qt program (indicating Qt bug), or whether the problem is in the application (KDE/App bug).

As a TT guy I'm inclined to assume they are KDE/App bugs until proven otherwise.

As a KDE guy I hope some of those alignment issues are actually Qt bugs, so they can be fixed in one place.

> - kmines bug?
> http://ranger.befunk.com/screenshots/qt-mac-apps/kmines.png

Normal OS X buttons come in one of two sizes, anything else is a style guide violation. So that app has to change here. (Resize the pixmap smaller, use a toolbutton instead of a normal button, or find an entirely different UI solution).

> - the statusbar frame collides with the dragger... kstatusbar bug?

Sure kstatusbar style issue. On OS X status bars can't have frames like that as it collides with the dragger. I suspect a KDE OS X frameless status bar style is the solution here.

> http://ranger.befunk.com/screenshots/qt-mac-apps/kjumpingcube.png
>
> - more text alignment problems.. this time in listview
>
> http://ranger.befunk.com/screenshots/qt-mac-apps/kmail.png
>
> - tab needs to be moved up one or two pixels imho.. or blended in

Alignment problems, these need to be investigated on a case by case basis.

> http://ranger.befunk.com/screenshots/qt-mac-apps/kopete.png
>
> - text not clipped in combo?

Not sure what this one refers to.

> http://ranger.befunk.com/screenshots/qt-mac-apps/kbruch.png
>
> - konsole tabbar bug?
>
> http://ranger.befunk.com/screenshots/qt-mac-apps/konsole.png
>
> - khexedit find button bug
>
> http://ranger.befunk.com/screenshots/qt-mac-apps/khexedit.png
>
> - calander navigation buttons not centererd
>
> http://ranger.befunk.com/screenshots/qt-mac-apps/korganizer.png

Alignment issues. Lots of them. Need case by case examination. (I'm a little out of the loop, there may be alignment fixes in Qt 3.3 I'm not aware of).

> - bottom line edit not panther like
>
> http://ranger.befunk.com/screenshots/qt-mac-apps/kcharselect.png

You mean it's too short vertically, could be a fixed height in the app.

> - stripes not panther like
>
> http://ranger.befunk.com/screenshots/qt-mac-apps/kbruch.png

Ah, I can't see anything wrong there, I guess I don't know what I'm looking for well enough. I do recall a stipes on panther fix being made for the latest release.

The splitter not being OS X style is a valid criticism. The other issues I think require KDE style or application fixes, or more investigation before they can be considered Qt bugs.

Don.

by anon (not verified)

> The splitter not being OS X style is a valid criticism. The other issues I think require KDE style or application fixes, or more investigation before they can be considered Qt bugs.

Thanks for looking :)

great job for TT on Qt/Mac overall though

by dood (not verified)

not with NWF (OpenOffice 1.1), but possible with native Qt (OpenOffice 2.0).. then again, a native aqua OpenOffice is planned, but not until 2006 ( :( )

by David (not verified)

It is good that Suse is funding this project, but I was wondering about other people who may be interested. I would have thought Lindows would have been interested in this project greatly.

Given that this is a long-term project and Suse may not be around that long (we can't be naive to the possibility - there will be a large amount of pressure to stop this eventually) projects like this need to continue.

by Anonymous (not verified)

> I would have thought Lindows would have been interested in this project greatly.

What's the problem? Lindows can still contribute to this project and speed up its development. There is no difference to e.g. both SUSE and Lindows supporting and promoting ReiserFS.

by ac (not verified)

Now you've done it. I'm gnawed off my own leg in anticipation. Are you happy now?

by Anonymous (not verified)

No, let's wait until tomorrow what you make next.

by ac (not verified)

They have delayed KDE3.2 for at least five months pal. Then after that, at least 5 more release canidates. Sorry about your limbs.

by Anonymous (not verified)

You must be talking about KDE 3.1.

by Mathieu (not verified)

HAHAHAHAHAAHA!!!

can't wait for that release..

if OO is Qt, KDE based, ... that means the application will be FASTER !!!!

i dont use OO 1.1, because it takes 10 mins to open on my P2-600

long live to KDE.

by SegFault II. (not verified)

I don't think it will be faster.
Maybe it draws faster (if at all).
But it surely won't start up faster.
More certain is the other way round, because it now needs to load itself and Qt as well.
But Qt is quite fast, so you won't notice this additional delay.
Which only occurs when no other Qt app is running...