KDE.OpenOffice.org: Native Widget Framework Available

A development version of the
OOo KDE Native Widget Framework is now available for
download. So far, it can draw KDE-styled push buttons, radio buttons,
check boxes and list boxes (screenshot1, screenshot2, Plastik). The OOo Native Widget Framework is a way to get the look of the host platform in
It does not affect the feel, because real KDE widgets are not used; the framework simply uses the QStyle API to draw its widgets the same way KDE/Qt would. It is currently developed for OOo 1.1, but it will be used in 2.0 as well.

A binary snapshot (i386 only) [85 Mb] is available.

Please note that it is a development version and that it contains bugs;
for example editable list boxes do not render correctly at the moment and you may need to unset your SESSION_MANAGER environment variable before running "setup" or "soffice".

Dot Categories: 


by JohnFlux (not verified)

So by Native widget they mean OOo's native widgets, not KDE's like it reads?
Is there really no other way than emulating the style? Can the real widgets really not be used?

Widgets that look like kde ones, but don't feel like it... great.

by Thomas (not verified)

Problem is, that a different approach (to replace the OO widget set with real qt/kde widgets) would result in a near 80% rewrite of the complete OO.org office suite. It's the same with other things like "hey, why not replace the widgets of gimp with native qt/kde ones..."
So I welcome this "emulated" look as an important step into the direction of at least giving the visual impression of OO.org playing nicely together with kde. (though I prefer the plastik style atm, but thinkeramik is also very good)
And I'm looking forward to using kdeprint directly with OO.org (and the lovely kde filedialogs).

by spamatica (not verified)

One is the KDE Native Widget Framework, which is the one being released, this is as far as I can tell the real deal, bindings to _real_ KDE.
The other is OOo Native Widget Framework, this is only an emulation to make it look more like KDE, it doesn't really help in anyway.

Following the links, that doesn't seem to be right. My impression is that the "KDE Native Widget Framework" is simply a specific implementation of an "OOo Native Widget Framework", i.e. it contains the code needed to make ONWF work with KDE.

by Boudewijn Rempt (not verified)

When looking into the CVS source of the Gimp today for an answer to the pressing question 'Why can I draw a nice, precise, accurate, connected line with the Gimp, and not with my Krita brush tool', I couldn't help noticing that the Gimp's UI and core are now really neatly separated.

Replacing the Gimp's interface with a Qt interface would be doable, and conceivably less work than creating a whole new image editor from scratch. Of course, it wouldn't be any fun, either, and you'd always be tagging behind the Gimp CVS to keep up, and you wouldn't have time to do something interesting and original, but it would be doable, quite doable. More doable than doing the same with OpenOffice, for sure.

Still, in the end, I think it's more fun to work on KOffice, and more rewarding.

But I'm going to take a second look at that little bit of mouse handling in the gimp's displayshell. I am sure that that's the trick.

by Fab (not verified)

Well what about the GTK-QT Theme Engine combined with those KDE filedialogs as found in the Sodipodi application

Anyway there seems to be so much integrative work going on. I'm losing grip :)

*GTK-QT Theme Engine

*Screenshots filedialogs Sodipodi application


by David Johnson (not verified)

Back a long time ago the "Kimp" people thought the same thing. It's logical. Just replace GTK+ with Qt. The problem was, IIRC, that the core of Gimp still assumes a GTK+ framework. For similar reasons, it was feasible to create a Gimp-plugin "plugin" for Krayon/Krita.

by Boudewijn Rempt (not verified)

I think you mean 'wasn't', not 'was' :-). I've guss actually read every posting on the kimageshop mailing list by now. And most of the Gimp source, both in its 0.99 and pre-2.0 incarnation, too. The Gimp has been cleaned up considerably by now (it has lots of GDK dependencies, of course, and that silly ersatz object-system in C, but not much direct GTK deps).

Not that I'd want to just port the Gimp over to Qt. I want to make a really useful artist's app out of Krita. But you have to give GTK one thing, I rather fancy, and that's that it was created purposedly for a graphics app. GTK has very nice functions that blast a region of memory filled with RGBA bytes to the screen -- with Qt you have to muck with QImage and then convert it to QPixMap, and then bitBlt it. That hurts performance.

Anyway, I'm still questing for a handy way to receive enough mouse events to draw an accurate line in Qt (i.e., not with a polyline!), and still have enough milliseconds to do some heavy computational work. But there's a chunk of code in the Gimp that's peculiarly licensed and that grabs, filters and mangles mouse events for the purpose of having enough of the buggers to draw an accurate line, and I guess that's where the trick is hidden...

by anonymous (not verified)

Out of curiosity what do you mean by peculiarly licensed? It's licensed so that you can't use it in KDE?

by Boudewijn Rempt (not verified)

No, I mean that bang in the middle of a single source file there is just a small chunk of code that declares that it's X11 licensed. That's kind of weird...

by Waldo Bastian (not verified)

That probably just means it was copied from some XFree86 library. X11 licensing is compatible with the GPL so it's really no problem. If you want to use it make sure to preserve the copyright headers + license that come with it though.

by Richard Van Den Boom (not verified)

You can use the kde printer utility by changing in the Generic Printer the command line from lpr to kprinter. The same as for gimp, Acrobat Reader and any other not too badly written program. Very useful when you want to print multiple times the same deocument with Acrobat Reader or Gimp.


by pezz (not verified)

Some screenshots of plastikized OOo: http://openoffice-et.sourceforge.net/pildid/OOo-1.1/ooo-plastik/

Thanks, Jan:)

by Fab (not verified)

Oh my ... that looks sweet ...


by Fabrice Mous (not verified)

Hmm made some screenies myself as well



KDE-OOo with the QtCurve-V3 style (from Craig Drummond) combined with OpenOffice.org1.1 toolbar icon theme (from Rohit Kaul)


by tanghus (not verified)

> Oh my ... that looks sweet ...

Except for that strange, north scandinavian language ;-)

by flex (not verified)

It's not scandinavian ... north european maybe, but not scandinavian.
Estonia is not a scandinavian country.

by tanghus (not verified)

OK - sorry. I thought it was Finnish

by Henning (not verified)

I wonder if every KDE style has to be implemented seperately for OOo.
Anyone knows how it works?

by ah (not verified)

All styles work out-of-box. These just happen to be done with Plastik style.

by Henning (not verified)

Ah sounds good :)
Hopefully scrollbars and tabs will be using KDE styles as well.

by StR (not verified)

Well... I do not like to use OOo because it is too heavy, it uses a lot of memory. I do not care if it looks like the rest of my KDE, because Itry not to use it a lot. It is too heavy for my PC.

If you are emulating kde, i guess it will consume more memory. I would prefer to have a native OOo with kde widgets...

So, for now, I use koffice, and if the .ppt is not understandable,... then i use OOo

by Jan Holesovsky (not verified)

The emulation works the following way: It uses QStyle to draw to a pixmap, which is then copied to the screen. Then OOo's toolkit draws the text over it. The difference between this approach and real Qt/KDE application is one bitblt operation (pixmap->screen).

The memory usage? One instance of KApplication, one instance of each widget to be "emulated" (QPushButton, QRadioButton, ...), and one temporary QPixmap. And of course shared Qt and KDE libraries, which anyone running KDE has in the memory anyway.

by David (not verified)

Mmm. That's quite interesting, and I'll admit to being ignorant of how this worked. Apart from running OO (which is memory intensive by iteslf) this doesn't seem to add much overhead. That's absolutely stellar work Jan.

by fault (not verified)

It should also be worth to note that this is how the Qt gtk engine also works; it makes QStyle draw to a pixmap and then make either OOo or GTK blit the pixmap to screen. Very little overhead and as fast as Qt drawing the widget by itself.

by JohnFlux (not verified)

I'm not sure whether to laugh or cry ;)

Either way, that's a very intelligent hack, and hats off to all involved, if only for geek points ;)

by gunnar (not verified)

ok, but must of the big vendors use OOo - and thats an important point.

--- and i am using it on an daily basis.

just my 2 cents ;-)

by Gerd (not verified)

Can we do the same with gtk?

by anonymous (not verified)

Yes, see the Qt-GTK theme.

by cloose (not verified)
by anon (not verified)

This is excellent work. Would it be possible to merge the work with crystal icons by default?


That would really complete the "kde look"!

by Kanwar (not verified)

Yeah something what Texstar has already done with pclinuxos ...
Check out: