JAN
8
2004

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
OpenOffice.org.
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".

Comments

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 JohnFlux at Thu, 2004/01/08 - 6:00am

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 thomas at Thu, 2004/01/08 - 6:00am

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.


By spamatica at Thu, 2004/01/08 - 6:00am

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 ac at Thu, 2004/01/08 - 6:00am

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 Boudewijn Rempt at Thu, 2004/01/08 - 6:00am

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

Fab


By Fab at Thu, 2004/01/08 - 6:00am

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 David Johnson at Thu, 2004/01/08 - 6:00am

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 Boudewijn Rempt at Thu, 2004/01/08 - 6:00am

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


By Anonymous at Thu, 2004/01/08 - 6:00am

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 Boudewijn Rempt at Thu, 2004/01/08 - 6:00am

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 Waldo Bastian at Fri, 2004/01/09 - 6:00am

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.

Richard


By Richard Van Den Boom at Thu, 2004/01/08 - 6:00am

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

Thanks, Jan:)


By pezz at Thu, 2004/01/08 - 6:00am

Oh my ... that looks sweet ...

Fab


By Fab at Thu, 2004/01/08 - 6:00am

Hmm made some screenies myself as well

screenies

http://www.xs4all.nl/~leintje/stuff/OOo-KDE/images.html

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

Fab


By Fabrice Mous at Thu, 2004/01/08 - 6:00am

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

Except for that strange, north scandinavian language ;-)


By Thomas Tanghus at Sat, 2004/01/10 - 6:00am

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


By flex at Sun, 2004/01/11 - 6:00am

OK - sorry. I thought it was Finnish


By Thomas Tanghus at Mon, 2004/01/12 - 6:00am

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


By Henning at Thu, 2004/01/08 - 6:00am

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


By ah at Thu, 2004/01/08 - 6:00am

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


By Henning at Thu, 2004/01/08 - 6:00am

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 StR at Thu, 2004/01/08 - 6:00am

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 Jan Holesovsky at Thu, 2004/01/08 - 6:00am

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 David at Thu, 2004/01/08 - 6:00am

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 fault at Thu, 2004/01/08 - 6:00am

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 JohnFlux at Thu, 2004/01/08 - 6:00am

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 gunnar at Thu, 2004/01/08 - 6:00am

Can we do the same with gtk?


By Gerd at Thu, 2004/01/08 - 6:00am

Yes, see the Qt-GTK theme.


By Anonymous at Thu, 2004/01/08 - 6:00am


By cloose at Thu, 2004/01/08 - 6:00am

This is excellent work. Would it be possible to merge the work with crystal icons by default?
http://www.kde-look.org/content/show.php?content=7131

screen-shot:
http://www.kde-look.org/content/preview.php?file=7131-1.png

That would really complete the "kde look"!


By anon at Fri, 2004/01/09 - 6:00am

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

http://www.pclinuxonline.com/pclos


By Kanwar at Sun, 2004/01/11 - 6:00am