Announcing Mozilla KPart A small group of KDE coders have ported Mozilla's HTML rendering engine Gecko to Qt. This is one of the most exciting developments to come out of aKademy, the recent KDE World Summit. The coders ported Gecko to Qt in 4 days, there is now a relatively small amount of work left to integrate Gecko into Konqueror where it will become an alternative to KHTML. On the night before the start of the hacking marathon Matthias Ettrich, Ian Geiser, Lars Knoll, Dirk Mueller and Zack Rusin were discussing integrating Gecko into KDE. Lars and Zack started looking at the Mozilla code to see if it would be feasible the next day and before the end of the marathon had a working port of Gecko to Qt's DOM. Gecko treats Qt like any of its other ports such as GTK or Win32. The remaining work is to integrate this port with Konqueror's web browser features such as KCookieJar and KWallet. It will then become an alternative HTML renderer for Konqueror. The developers are keen to stress that this does not effect KHTML in any way. They consider KHTML to be the superior engine for its clean design and fast speed. KHTML will continue to be the default rendering engine for KDE. The purpose of this port is to use KDE's excellent component architecture to offer a choice to users and distributors. The choice of rendering engine will make no different to Konqueror users except for the small number of websites where KHTML and Gecko differ in their rendering of the HTML or Javascript. The look and feel will remain the same including native Qt widgets. There have been attempts at similar ideas in the past, QtScape, Corel's port of Mozilla to Qt and KMozilla using XParts however none of these were maintained. Lars and Zack have committed themselves to maintaining this code. It is hoped to have this work in CVS as soon as possible. The Qt port will be maintained in Mozilla's CVS while the code to embed the QWidget will be in KDE's repository. A release time is uncertain as this will depend on the next stable release of Mozilla. Mozilla Foundation said.... Conclusion... ---- On Sunday he, Lars Knolls, matt ettlich, Ian G, and Dirk Mueller, went and were atlka bout integrating gecko into KDE. On Monday him and lars looked at the code to see if it would be feasable. 4 days later they have the native port of gecko engine to QT DOM. This has no implications on KHTML, it is just an option for HTML rendered. KParts is a great architecture but only 1 HTML renderer so far. It will not be any notice to users. Zack and Lars will maintain the code. Will be maintained in Mozilla CVS which will have the port, the code to embed the QWidget will be in KDE CVS. QtScape then Corel's Mozilla code to port to Qt but that wasn't complete and wasn't maintained. XParts a KPart variant made KMozilla but wasn't maintained. How long been working on this, 4 days, 2 developers took 4 days. Mostly because KDE and Qt is easy to work with. Not too impressed with Gecko interfaces. They want a good relationship with Mozilla developers. How difficult Will this replace KHTML? Up to the distributions. KHTML is superior because code base is a lot cleaner. Uses Mozilla javascript engine. Any speed or memory usage issues? No benchmarks, seems a bit slower, some issues will be solved in the coming weeks. Other HTML engines? Opera? Nope. Opera may be intereseted what's it all about does it require modifying gecko? No, just used their interfaces. Just adds a qt port similar to how they have a windows or Mac os port. what is mozilla development like compared to kde? technically and socially dunno, ask Mozilla foundation. will it be in 3.4? it will be in CVS as soon as possible, depends on next stable release of Mozilla because they are working with Moz CVS just now. widgets are KDE native, everything done through Qt. including file dialogues KIO slaves not yet integrated but being worked on. cookie support soon. kwallet being worked on.