OpenOffice.org 2.0.2 has been announced. Among other new features, fixes, and improvements, this version contains the KDE Addressbook Connector by Éric Bischoff, and Crystal icons from KDE, many newly created by Nuno Pinheiro and Robert Wadley. The Crystal icon set for OOo is not yet complete have a look at the status page if you are interested in helping. Both the KDE Addressbook Connector and the Crystal icons were already available in ooo-build, so you may already have them if your distribution uses ooo-build as a base for the OpenOffice.org packages.

Comments

I like OpenOffice with the KDE look and feel... But I would love it even more when there would be a Firefox with KDE look and feel. (And NO Konqueror is not yet 100% exchangable with Firefox, even when it passes the ACID2, it still needs a RichText Editor option).

A long time ago (in a galaxy far far away...) I saw a KDE version of a very old Mozilla (Firefox?) Version.

Wish I had enough KDE/QT knowledge, then I would have done it myself....
But as long that this isn't the case, to those who can: KEEP UP THE GOOD WORK!!!

Firefox/Qt is a good example of something that has been done 90%, but the
most important 10% are still missing... Probably partly due to mozilla
people not wanting to give cvs-write access to some KDE devs.

A sad story, especially if you remember that Firefox/Qt was (re)created/announced
in August 2004, one and a half year ago.

All of that work (the 90%) was done in 1 (one) week.

Since then it has seen no more work, mainly due to the cvs-problem mentioned above...

There are talented hackers around which want(ed) to continue the port, but probably (unfortunately) they have lost the interest, for the mentioned reasons...

Maybe Mozilla-people are just scared to the point that, if the Qt-port would be complete, they could notice that betting on gtk+ for the past years was not really a good idea...

I hope this might chance as Qt4 becomes more widespread. As Qt4 exists for OSX, Win32 and Linux, it might be quite a good idea to use it as a toolkit for firefox, as it look and feel is more integrated.

Konqueror shouldn't have all these things. They're different browsers with different approaches and strengths. I use Konqueror at times and am grateful for it. For my daily browsing however, nothing but FireFox will do.

To give Firefox 1.5 the KDE filepicker for "save-as" actions in a KDE environment, I have used the following work-around:

1) locate the file nsFilePicker.js.
For me (working with suse 10.1) this is in the directory:
/usr/lib/firefox/components/
2) To be sure: make a backup copy of that file
3) Edit the file nsFilePicker.js and search the following code fragment:

4) As a last step we have to reset the chrome register.
For this I add & subsequently delete an item under tools/extensions of Firefox. (there must be amore intelligent way ...)
5) Enjoy your KDE style filepicker

Well if it doesn't integrate with GNOME, I keep wondering why it wants to start natilus (something that remines me of a filemanager from 10 years ago atleast.., no features).

If I could work with natilus it would be find to, but just opening a konqueror filemanager or make it optional what will be opened from the download manager, would make firefox under linux a totally differnt experience...

A Plastic theme for firefox already exists. So even if it remeans GTK+ only, the only big problem is the fixed filemanager integration.

IIUC, Firefox-1.5 reads the XDG MIME database which is not GNOME although GNOME uses it. Details should be available on freedesktop.org.

Also, Firefox and Thunderbird have an ECMA script file: "prefs.js" which controls some stuff. It is located in a subdirectory of: ~/.mozilla or ~./thunderbird. You should NOT edit this file, but rather place your changes in a "user.js" file in the same directory and restart the app.

When I click on a link in Thunderbird, it opens the link in Konqueror. This took three lines in the Firefox "user.js" file:

"Well if it doesn't integrate with GNOME, I keep wondering why it wants to start natilus"

Firefox does listen to Gnome settings.
If you make kmail default in Gnome, firefox will start kmail when clicking on a mailto: URL

Firefox does not listen to KDE settings.
If you make kmail default in KDE, firefox will either start whatever was default in Gnome on your system, or give the "brilliant and very user friendly" error message that the protocol 'mailto' is unknown.

To get firefox use the mailapplication on platforms other then gnome, one needs to hack into 'about:config' and create a proper string for it.

I keep wondering the same thing every time it shows me that horrible gnome/gtk file dialog. But I've got to agree with what other people have said, I'd much rather have Konqueror get competitive since Mozilla has consistently put out an inferior version on Linux than other platforms (at least windows) because of their use of gnome/gtk.

And while we're on programs that we need natively on Qt/KDE, how about a proper high-end paint program? GIMP suffers from all the same integration issues that Firefox does as well as having a development team that consistently shows that they have no clue what so ever. Blaming gtk when your software doesn't work is inexcusable. Lack of tablet support in any professional paint package, whether wannabe or not, is unacceptable on any level. And after wasting years screwing around porting to gtk2 instead of actually implementing features or fixing bugs you've got no excuse.

Unfortunately I don't have enough knowledge of C++ or Qt to do any of this work myself, but I'm really learning toward getting some. Because a full featured web browser and paint program are the two things that keep me from being able to do all of my work on Linux.

In the first place, the Gimp has tablet support. In the second place, ever heard about Krita? We've been putting lots and lots of work into a high-end paint application using Qt and KDE for a couple of years now.

If KDE people want to blame the lack of a port on mozilla.org not giving them special treatment, that's their choice. Zack Rusin had CVS access long ago, the controversy came along with Dirk Mueller decided that he shouldn't have to go through the same process that everyone else has gone through.

I need richtext for some people who don't know HTML, and they are very very happy with it. There is an option to look at the source (very primitive alas) so I can do anything that isn't normally possible with an richtext editor.

But because of this, it keeps me fixed on firefox (or seamonkey).

I would love to be able to do it with safari or konqueror for that part. And I know they are working on something in safari, and are or have been working on a cursor for konqueror, but to my knowledge it is still far away from a fully working example.

I don't really know what meltdown is, when I looked at some examples, it looks more like just writing text and html....

This is really nice to see. I am wondering however if anyone has come across the following issue. When I enable the openoffice-kde integration on Suse 10 or 9.3, the open file dialog is terribly slow. Using Openoffice.org's native file dialogs, the same operations are lightning fast.

So has anyone else come across this and is there anything that can be done about it?

they won't
suse only provides upgrade packages for suse packages that contain bugs.
And suse offers some additional upgrades (supplementary directories on the ftp server), but they don't include openoffice.org

That's because OO.o starts an external app "kdefilepicker" when you want to open files, so this incurs all the usualy KDE app start-up delays each time you access files! Notice also, that when the file selector comes up it is a top-level window (gets a taskbar entry, etc) with a 'X' icon, and not the OO.o icon. (They could've at least made the kdefilepicker "transient" for the OO window)

Also, the themeing is not that brilliant, notice how the toolbar icons, or pushbutton text, don't move when the item is pressed - even if the KDE theme says they should.

"That's because OO.o starts an external app "kdefilepicker" when you want to open files, so this incurs all the usualy KDE app start-up delays each time you access files! Notice also, that when the file selector comes up it is a top-level window (gets a taskbar entry, etc) with a 'X' icon, and not the OO.o icon."

So, that's the reason OO.o doesn't full support kioslaves yet, I guess.
Does anybody how is things going related to this subject?

It isn't. Even if the filepicker was launched from within OpenOffice.org, as oposite from an external script (to avoid linkage), there wouldn't be any changes in that regard. KDE filepicker would return either way the very same URL. You either have to add KIO support for OOo, or, better yet, make filesystem be in userspace on Linux like in a microkernel (ie. FUSE).

GTK programs also need to be better integrated into KDE. KDE should not be about toolkits. I mean whxy shouldn't Abiword when executed under KDE use the KDE-file dialogue. It must be possible to reimplement the KDE filedialogue for GTK.

kde people have actually looked at this in the past and IIRC, at least when they did that a year or two ago, the gtk+ calls for the file dialogs are not well suited to being used with ours. API concept conflicts, in essence.

what i'm getting at is that there's more to this world than KDE. we can do only so much, and to be honest we've really been leading when it comes to integration issues. look at who's taken the common event loop stuff most seriously, for instance (hint: Qt). then look at IPC, multimedia in KDE4, etc... hell, the whole RUDI concept came from a KDE guy.

while i agree that more seamlessness is an excellent goal that we should work towards, it takes more than just KDE and to be honest i think we've been doing more than our job in this regard.

In layman's language, that means that the GTK people would rather integrate GTK with Windows than they would with KDE, even though it is totally possible for them to do so, for reasons which are best known to them. It certainly isn't a licensing issue, which some of the Eclipse people have really hidden behind.

I have to say I'm not keen on the concept of RUDI (a layer to target multiple desktops and XFCE, which no ISV or company will go for), and the only part of it I like is trying to solve the practical problem of binary compatibility (although trying to solve that may end up with the former being possible!). It just tries to go too far to somewhere which is just ultimately not possible in my opinion, and from all I've read.

The effort going into sensible integration, and ideas for integration where possible, currently all seems to be one way. If you point out something that "Just Works" inevitably there is a licensing issue or something else as to why it shouldn't be used or shouldn't be done.

"kde people have actually looked at this in the past and IIRC, at least when they did that a year or two ago, the gtk+ calls for the file dialogs are not well suited to being used with ours. API concept conflicts, in essence."

I mean a reimplementation in GTK with no KDE dependencies and using the gtk calls/interface.
A clone of KDE file dialogue so to speak. KTK as GTK people will probably not accept the patch and it would be wasted time to battle on that front.

Eclipse is another kettle of fish altogether... hopefully I can explain it correctly.

Eclipse uses SWT, which is a whole new toolkit. SWT, however, provides hooks so you can implement it with native look and feel. Any of the widgets that exist in SWT, but not natively, will just be rendered by SWT.

Because of this Eclipse can now use a lot of Windows widgets when running on Windows and GTK widgets elsewhere.

The Qt-SWT bridge has already been written, but was never released because of licence incompatabilities. I know there was a sort-of campaign to have the two parties come to a compromise, but it kind of fizzled I guess.

So if the legal issues can be bridged, a full KDEized version of Eclipse is technically very possible because of the way SWT allows native widgets to render certain parts of it.

Trolltech already gave the go-ahead to use Qt with SWT on the condition that SWT was under a legitimate open source licence. The question of legal issues is more of a FUD tactic that was more than likely due to the code not actually having been written.

GPLv3 is supposed to play better with patents though (which was the supposed incompatibility between GPLv2 and CPL) so perhaps once that goes final we'll go and try and get them to give a new excuse for not releasing it.

"GTK programs also need to be better integrated into KDE. KDE should not be about toolkits. I mean whxy shouldn't Abiword when executed under KDE use the KDE-file dialogue."

This is a problem for the GTK people, not for KDE. At the moment, ironically, integration with Windows seems to be more a priority for them than integration with KDE. Many people want to deny that integration of GTK and KDE is possible, using the usual, same old, same old reasons, licensing issues etc. etc. but it is perfectly possible.

I still want to see openoffice not to confuse klipper anymore. Whenever i select an textobject an image of the selected textobject gets copied to the clipboard and not only once. Same for just selecting images. I read about in 3.5.2 you will be able to disable images completly in klipper but of course this does not fix the bug in OOo but at least it is a work-around :o/