Among the most exciting things to come out of aKademy, the recent KDE Community World Summit, is a Qt port of Mozilla's Gecko rendering engine. This will give Gecko the full native look and feel of KDE/Qt, and make it available as a KPart, where it can provide an alternative HTML renderer for Konqueror.
"This is the best of both worlds for KDE" said Lars Knoll of the KHTML
project. "Integrating Gecko side by side with our existing renderer
opens a lot of doors, without any compromise of the hard work and clean
design that make KHTML what it is."
On the night before the start of the hacking marathon, a conversation
including, among others, Ian Geiser, Lars Knoll, Dirk Mueller, and Zack
Rusin happened onto the topic of integrating Gecko into KDE. Lars and
Zack jumped into Mozilla's code, to see how feasible such a plan might
be. Within four days (and before the end of the marathon) the two had
a working port: Gecko running on Qt. They credited the speed of
implementation to the maturity of the respective technologies and KDE's
component architecture (though the caliber of the hackers certainly
didn't hamper the effort). In their implementation, Qt is just another
platform for Mozilla, parallel to the drawing and widget layer for
Mozilla's other platforms like GTK, Win32, or MacOS X. Though the work
is on-going, the team is close to integrating Gecko into Konqueror,
connecting Gecko to the higher level browser machinery in Konqueror
such as KWallet and KCookieJar.
The Mozilla organization was supportive: "We are delighted to work with
the KDE community, both to extend the reach of Gecko, and to be part of
an effort bringing even greater depth to the KDE desktop. Making Qt
another platform for Mozilla, and Gecko another option for KDE is a win
for both users and developers" commented Mitchell Baker, President of
the Mozilla Foundation.
There have been previous starts at this idea in the past. Trolltech's
QtScape, some initial Corel work, and a Mozilla-based XPart, foundered
from lack of maintenance and little advocacy within the Mozilla
community. The current team will be full-fledged contributors to the
Mozilla code-base, with KDE people and mozilla.org behind the effort.
The Qt port will live and develop in Mozilla's CVS repository. The
code to embed the corresponding QWidget will live, naturally, in KDE's
repository.
Comments
You're comparing different urls ;P
Uh........ you aren't using Konqueror 3.3 are you?
Here is a screenshot in Konqueror 3.3:
http://128.61.66.26/snapshot4.png
Since they use Quirks mode, no browser is supposed to show this correctly
Which theme for Firefox do you use?
I am very pleased to see this project. Konqueror does most of the things right already (I've been using it as my default browser for a couple of months now), but there is one thing only the Gecko engine is able to do on Linux right now: in-page WYSIWYG editing. If I get it right, a Konqueror with the Gecko engine should be able to run the existing Mozilla-based WYSIWYG-editors like HTMLAREA or Kupu. That would eliminate one of the last reasons for me to still use Mozilla/Firebird from time to time ...
Maybe you should check out Quanta. It's "Bleeding Edge" branch features just that, and yes, that's based on KHTML.
I think Joachim means in-page HTML editing, just like a textarea but with bold, italic, lists, tables, images, etc. that generates HTML that can be submitted with a form button to a content management system, not a full WYSIWYG editor for HTML-files.
No need for using the "Bleeding Edge". Quanta 3.2 and 3.3 has the WYSIWYG (VPL) support. Well, by mistake it's disabled in the 3.3.0 release, but it's there and mostly works. And it heavily depends on KHTML, so I hope that it's development won't be stopped. ;-)
Koos Vriezen today posted his first try at implementing Mozilla's MIDAS editing. See
http://lists.kde.org/?l=kfm-devel&m=109501847920318&w=2
I don't think many understand the ramifications of this news!
Now we can have all the Mozilla apps, firebird, sunbird, etc.., as well as the mozilla platform internals XUL, XBL, XPCOM, spidermonkey, etc. work with QT and KDE.
This is the best news I have seen all year..
This are really great news.
Does anybody know if this will also be available for kde 3.3 or just for 3.4(4.0)?
Tom
Please please do *NOT* kick khtml.
Make "kfirefox" a choice (optional), but khtml is just so cool.
khtml is THE choice for me, and as maybe some of you know: even the "brand new firefox" has its old contamination (hope this is the right word) whereas khtml s so clean and *small*.
- khtml fan
Are you retarded or brain damanged? Who said that khtml is depreciated?
I wouldn't worry if I were you. I recall that when the Navigator 5.0 source release was announced, there were two camps: the people who got all excited that KDE could integrate Navigator components, and people who were upset that the KDE-native engine might die. It's been a few years; KHTML is still around.
Still, it's nice to have the option of using Gecko. May the best engine win.
I gotta say i'm quite happy about this development
first of all because firefox never looked right in kde due to its gtk themeing
and second of all if they manage to seperate Gecko Engine from Mozilla properly as kpart then i can use Konqueror Exclusivly and for me it means less space being used
well, thats good we now have a new standalone browser made with Qt/KDE libs.
know, we need konqueror ship as a standalone packages (with khtml)
what about fix from apple, long time I have not heard about new commits from Apple. they are at version 1.25 in Safari 1.2. And gmail works fine in safari but don't in konqueror. please get the new fixes.
http://developer.apple.com/darwin/projects/webcore/
> please get the new fixes.
Getting them is easy. But extracting them from there and merging into khtml is the work.
Getting "magic fixes" from WebFork is not easy, mind you.
There's no public CVS. All you get is a big fat tarball with very few hints about what changed or why.
Was it something really wise, some one-time dirty hack to keep a common DHTML script happy, or some pointless rename-half-the-methods-so-PHBs-think-we-are-going-ahead (they do that at every friggin release)?
You take your pick painfully after hours of code scrutiny, and that is not exciting.
wow,... if only I knew....
sharing a same repository would not have been an option ?
I guess they don't want to...
and I suppose they are not generous enough to send patches for important stuff .... its another marketing thing who does not help anybody.
what about the first few ? does Apple gave more collaboration, or that just was as painfull ?
The first time I skimmed this article, I had the sense it was more one-sided than it actually is. The author /did/ acknowledge that the ease of porting was due to the design of both KDE and Mozilla. My original reason for returning to the article to respond was to stress that Mozilla's design was probably a significant element in the success of the effort. After reading it again, that's not necessary. Nonetheless, I do want to point out what appears to me to be a very noteworthy aspect of Mozilla's design approach:
http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/rules.html#int...
I've never actually written code using the approach, but it does seem to provide a framework for very clearly defined interfaces. I'm not saying KDE should or could use that exact approach. I'm just pointing it out as food for thought.
...they finally ship Gecko separated from all their Mozilla products. That is something they promised to do for years but still haven't realized. Currently non-Mozilla project still have to rely on and be compatible to a particular version of a full whatever-Mozilla-product installation. Also within the Mozilla products available at one given time the discrepancy between the used Gecko version in Mozilla, Firefox, Thunderbird etc. is a whole mess and a whole lot of unnecessarily duplicated code on the HD, and every single update to either the UI or the Gecko core pushes the user to update the whole thing again.
Considering that the Mozilla foundation is concerned about market shares for their XUL technology (which I agree is great) I have to seriously question their priorities, a Gecko runtime should have existed from the very beginning instead keeping it bundled with software demoing the technology and breaking compatibility to third party software with each version.
For those interested in contributing to Mozilla (and supporting its use in other projects) and wondering what I'm talking about, look at http://www.mozilla.org/projects/xul/xre.html (stalling since nearly two years now).
when will be binaries/source be released? Should one has to wait for KDE3.4 or KDE3.3.1?
I need hacher programes
No, you need a spell-checker.
asl3amo alakom
i want some hack programes
and thanx u at all
thanx my friend
yours
salah
It has been a long time since this announcement, i've thoroughly searched google, but haven't a clue what has happened. What is the status of this project?
http://www.kdedevelopers.org/node/view/976
Thanks for the link...i'm pleased to hear it hasn't died, and will wait excitedly for the first release.
I would be happy to have a qt ported firefox since I have absolutely no gtk support whatsoever installed and I don't intend to install it anytime soon only for the sake of one application. On the other side to address any of my university issues (like registering for curses or exams) I have to use a site which doesn't work under Konqueror. So... what is the status? Any other browser using qt?