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.
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.
Here's the bug report in Firefox's bugzilla that asks Firefox to use the KDE filepicker when running in KDE:
However, the best solution would be to iron out the bugs and usability issues in Konqueror web browser (http://Konqueror.org) so that we have a KDE solution with true desktop integration.
Konqueror is not (and will never be) a replacement for Firefox. Among other things, it doesn't have:
1) FF's vast extension library
2) commercial plugin support
3) a large installed user base (important for web devs)
4) that certain jene se qua of a gecko engine
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:
2) To be sure: make a backup copy of that file
3) Edit the file nsFilePicker.js and search the following code fragment:
//@line 278 "/usr/src/packages/BUILD/mozilla/xpfe/components/filepicker/src/nsFilePicker.js.in"
//@line 280 "/usr/src/packages/BUILD/mozilla/xpfe/components/filepicker/src/nsFilePicker.js.in"
Now replace the line with:
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
While it is true that Firefox does use the GTK+ toolkit, it is not GNOME compatable either.
It would probably be easier to integrate it into the KDE desktop if it conformed to the FreeDeskTop.org standards.
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.
> I keep wondering why it wants to start natilus ...
This is configurable somewhere, it is not built into Firefox!
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:
This points to a short Bash script: "konqueror-URL".
I presume that similar configuration can be done for Firefox.
"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.
> Firefox does not listen to KDE settings.
The Firefox people are waiting for those patches.
It's not forbidden for KDE developers to collaborate with other projects.
As I said, Firefox listens to XDG MIME info:
and KDE doesn't use this yet.
There's probably a more "right" way to do this, but I managed to get firefox to open konqueror rather than nautilus by changing /usr/share/applications/nautilus-folder-handler.desktop.
Exec=nautilus --no-desktop %U
I would assume that there is an override for these settings in your home directory structure but I didn't get around to finding it.
Hope this helps
Make a file " in: "~/.mozilla/firefox/default./" called: "user.js" and put something like this in it:
only have the app you want (with the full path) in place of thunderbird.
Restart Firefox and it should work.
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.
Very much agreed. It would be really great to have a Firefox which integrated into KDE
"it still needs a RichText Editor option"
Try using Markdown instead. You'll eventually get to a point where it's cumbersome to enter rich text in any other way.
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....
What is the "RichText Editor" option in Firefox? I can't seem to find it. Is this something like NVu?
There is an option to use old XUL dialog. Otherwise Opera is a good alternative.
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?
Finally, does anyone know whether Suse plans to provide upgrade packages for Suse 9.3 and Suse 10?
"So has anyone else come across this and is there anything that can be done about it?"
Noticed it as well, must be the overhead of the kde-integration package.
" Finally, does anyone know whether Suse plans to provide upgrade packages for Suse 9.3 and Suse 10?"
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
Use apt and add "suse-projects" to the repository list. It has 2.0.2 right now.
Of course Suse offers updated Openoffice (and some other applications):
2.0.2-0.3 is Release Candidate 3 !!!
you can check the discription inside the rpm-file.
Then download 2.0.2-1, that's the final release.
ah, finally it's online :)
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.
and in your mind what is the Gtk+ project's role supposed to be in all this?
> what is the Gtk+ project's role supposed to be in all this?
Actually, fact is that today there are important apps for gnome and kde and when Gnome would go, we could expect gtk to get visually merged into KDE.
So the formula KDE app sphere = qt is wrong despite that KDE is qt based. And the formula gtk = gnome is flawed.
The clean solution is a patch for the latest gtk/gtk+, let's call it ktk which replaces the file dialogue. When you compile programs with ktk patched gtk you will see no difference in behaviour.
Another "ugly hack" for the same is http://www.kde-look.org/content/show.php?content=36077
Perhaps Rudy kan take care of this :o)
> The clean solution is a patch for the latest gtk/gtk+
now who do you think has the ability to apply this patch upstream?
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.
It too think that a replacement for the standard gtk dialogs of gtk programms running within kde would be nice. That stupid gtk file dialog in eclipse is really annoying me.
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.
Azareus is also a SWT gui, which could benefit from the same.
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.
> 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.
As far as I know, there is at least a eSWT implementation for Qt Embedded available for OEMs with IBMs WebSphere Everyplace Micro Environment. So, IBM should have some code for SWT on Qt.
But I also heard some rumor, that the legal issues at least for SWT on Qt Embedded are solved. But I don't know anything more specific.
I saw this the other day, but never tried it:
An interesting concept nevertheless.
"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.
Patched GTK needs not go upstream. As long as KDE maintains a patched GTK, I bet many distros will provide the patched version to the users.
Does anyone know if OO.org 2.0.2 has fixed the list bug yet? I can't make heads or tails of the bug report as to whether this has been fixed.
just want to note at this place too, that the icons for printdefault and printpreview are not consistent with other KDE print icons.
OO - printdefault = KDE - printpreview
IMHO this needs to be corrected.
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/
Anyway... 2.0.2 integrates nicely into my KDE and looks really nice :o)