Today the KDE team announces a new project to re-synchronize our HTML engine,KHTML, with the WebKit engine. Code named Unity, the project has so far focused on porting the WebKit engine to Qt 4 with minimal changes to the existing code-base. WebKit is a derivative of the KHTML engine developed by Apple Computer Inc.

The initial work for this project was done by four KDE core developers at theKDE Four Core meeting last week in Trysil, Norway. The contributors were
Dirk Mueller, Zack Rusin, Simon Hausmann, and George Staikos. The project also builds on lead-up work done over the past year by George Staikos and Maksim Orlovich, which synchronized the KDE and WebKit Javascript engines.

At this stage Unity is a research project to determine the feasibility of
merging much of the KHTML work done over the past few years into WebKit. This
will provide us a means to synchronizing our engines. There are no concrete
plans to replace KDE's current KHTML component, which is also used by Konqueror to render HTML pages, with Unity. Any such decision will be left to the KHTML and KDE core
development teams in the upcoming months. It is dependent on many factors such
as our ability to keep the engines synchronized over time, our ability to
produce a high-performance, stable, and complete KPart, our level of comfort
with the new code-base, and our ability to come to a suitable working
arrangement with the other WebKit contributors.

With respect to the technical work, our efforts have resulted in a Qt 4 based WebKit library that is able to render a variety of web pages quite nicely. There is still a considerable amount of work to do before it can be considered a complete browser engine on our platform but the basic foundations are complete. The KDE build system, cmake, is integrated into the WebKit sources, rendering uses Qt's graphics facilities, and a simple test driver has been developed. A KDE layer will be added to integrate the engine with the desktop facilities provided by KDE as well as creating a KPart which can be loaded by any KDE application requesting a handler for HTML.

Comments

It may be just the quality of the screenshots, but they look a bit vague, almost out of focus. Is the a real phenomenon (maybe due to Qt4's drawing?) or is it an artifact of the screenshots and nothing to worry about?

Of course I clicked on them. It is the text I am worried about. Antialiasing is fine, but this looks out of focus, and would be very tiresome on the eyes. I tried reading the KDE page screenshot, and I'm glad my KDE 3.5.3's Konqueror renders a sharper page...
Back to my question: can I conclude this effect is real then?

Well, I'm using a TFT and it really hurts my eyes looking at those screenshots. So either my pixel arrangement is different from the poster's or the poster has a really wacky setup which he got used to and actually thinks is sharper than what he had before ;-)

I think it's the subpixel arrangement. If I'm an inch or so from the screen, it appears that the subpixels are "reversed" from where they should be... i.e., the red is on the right side of the pixel and that's down the right side of the character creating a halo effect on that side. Same goes for the left.

I'm sure it looks great if your screen physically matches the subpixel layout.

Perhaps the hinting was set up differently on the machine where the screenshots were taken. Different monitors sometimes require different sub-pixel hinting styles due to the way the screen is laid out.

What exactly do you mean by 'good support for AJAX pages'? Konqueror does support XMLHttpRequest, the only problem is that various 'hacks' are used to make DOM-manipulation cross-browser, and once again, people conclude your browser is either IE (which does not support all W3C's DOM methods), or Mozilla/FireFox (which has some oddities as well).

I mainly develop on Konqueror, using the W3 methods (using AJAX as well), and 'hack' around the various buggy implementations found in other browsers.

Well http://alpha.qunu.com/ doesn't work right, http://www.bestbuy.com's menus don't pop down after a mouseover (not AJAX but its in JavaScript I think), and http://www.bluedot.us's edit Dot feature doesn't work right. None of them are sporting the W3C seal of approval so I guess they might not be W3C standards compliant. Note that all of those work in Firefox 1.5 and I thought that Firefox 1.5 would be sticking just with the standards and not pulling a Microsoft on us but maybe not.

btw I might make a ebuild for the Konqueror SVN. What folders would be the ones I would want to work with? The SVN layout confuses me :/

Konqueror itself had a moderately annoying bug in XMLHttpRequest back in KDE 3.4 where it was appending a null byte to the end of every POST request (bug 113393). Can't say that any of the other browsers have been very fun to work with either, though.

me too ;) the only reason I'm sometimes forced to use firefox is those fancy websites that do weird complicated things with javascript n'stuff. I'd much rather do everything in konq; firefox reminds me more of windows every time I try to use it :(

Line 532: {HTMLElement.prototype.removeNode=....
hmm ... we know that HTMLElement prototyping doesn't work out of the box in KTHML-based Browsers - so it seems like they didn't even test their stuff in Safari!

Of course it didn't work --- it's non-standard behavior that's basically an implementation detail of Gecko! Comparable code for Konqueror would be to use
window["[[Element.prototype]]"]. Unfortunately typical "Web 2.0" webmasters seem to think that IE and Mozilla are the only browsers, forcing other browsers to emulate things like this, and also non-standard language extensions like getters/setters (typical pattern seems to be to use Mozilla extensions to emulate IE extensionw). This does, BTW work in upcoming 3.5.4 to some extent (just for the base classes, KHTML doesn't have separate prototypes for divs and such); and to a fuller extent in development version of Safari.

Which impact does this have on KDOM2 and KSVG2? I think KDOM2 has a really great concept behind.
Is Webkit beeing ported to that, or would we "loose" that development efforts if we would go WebKit directly/only? Can anyone involved shed some light?

Rob Buis, one of the developers behind KSVG2 is currently working in the Webkit camp. The most up-to-date version of KSVG2 resides in Apple's repository. Rob told me they plan to port the "good" parts back to KDE.

Personally i'm interested in Patternist, currently residing in KDOM. It is an XPath 2.0/XQuery 1.0/XSL-T 2.0 implementation(not complete though, but good on its way). Once integrated, it will provide those technologies to the whole of KDE. And Konqueror will have features other browsers are light-years from acquiring.

I also heard about patternist some time ago, and i really think it is a great base for anything dealing with XPath/XQuery/XSL. I always thought that patternist would be used in KDOM2 and thus also be used in KHTML2/KSVG2. Is this wrong? (You stated it resides in KDOM)
The next question is: if KSVG2 is developed inside WebKit, is KDOM2 also in WebKit? I was always under the impression that KSVG2 and KHTML2 relied on KDOM2 as a common base. Is this also wrong?

Anyone care to enlighten us more? Any information would be greatly appreciated!

Patternist resides in KDOM(that is, kdenonbeta/kdom/patternist) but does not have KDOM nor Webkit as dependency. The only essential dependencies are QtCore and kdecore(although Patternist did have a significant dependency on the KDOM library once).

So, the dependency goes the other way around; KHTML will depend on Patternist in order to get XSL-T support, for example. Similarly, if KOffice will want to use XSL-T for its import/export filter(or whatever), it will link to Patternist.

The good part is that Patternist isn't hard coded on a particular tree implementation(which for example KHTML/KDOM/Webkit/Unity is) meaning it's possible to query anything if one sub-classes a couple of classes. QDom, KHTML's tree, or pretty much any hierarchical data.

The idea is to move Patternist into kdelibs/patternist since it is the lowest denominator of everything, but it /might/ be some other place will be more suitable now with Unity and all, although I currently doubt it.

* No, Patternist doesn't use KDOM's tree implementation. KDOM has an implementation of W3C's DOM XPath Module. That is, the implementation acts as glue code adapting Patternist's APIs into the DOM API(which is a very limited subset compared to Patternist's). So, KDOM depends on Patternist in order to supply the XPath DOM API.

* No KDOM2 exists. KDOM, kdenonbeta/kdom, exists, which originally was derived from KHTML during KDE 3.x(kdelibs/khtml). Nikolas Zimmermann(one of the main hackers on KDOM) have said he consider KDOM dead because work is taking place elsewhere. However, KDOM contains tons of code that can be integrated elsewhere(such as XPointer, OASIS XML Catalog 1.1, XInclude 1.0 and DOM 3 Core implementations).

* KSVG2 is the rewrite of "KSVG". KSVG is the one used in KDE 3.x, in kdegraphics. KSVG is not relevant in these discussions.

* KSVG2 is(or was) being integrated into kdelibs/khtml in branches/work/khtml-svg(by Nikolas and Rob). However, it's been a while since that was active so perhaps it will start all over now with Unity and that general KHTML development has proceeded.

* The project called "KHTML2", kdenonbeta/khtml2, is pretty much dead as far as I know. It was an effort to put KHTML on top of KDOM. Carewolf(Allen, the CSS hacker) have expressed it's no way that's going into kdelibs. It's also in general rather old and obsolete and not into the loop of recent developments.

* When Apple was in the early stages of opening up their repository and acquiring SVG support by using KSVG2, they ported needed parts from KDOM into Webkit(IIRC) and the two bases were mutually synced for some time at the beginning. But KDOM as a whole is not in Webkit. However, the code bases are quite similar in this area so KSVG2 operates directly on top of Webkit.

All this is very confusing as one can tell, and I many times think it's rather unproductive because of all the projects in action where little synchronization and planning is taking place. In several cases decisions have been made which has down right hurt other projects.

And of course, I can be wrong above or have missed something, it's not easy to track all this :)

Sorry, but I don't get the bigger picture about the relationship between KHTML, KJS, WebKit, Unity etc.
Could someone please explain, what relies on what, and where the distinct parts are used? (A link would do as well.)

A long time ago Apple forked KHTML and KJS, creating WebKit. Since then both codebases has seen lots of development, some code they share and in other areas they differ. In short Unity is a project trying to merge the two again, making a more unified codebase.

Some time ago there were great announcements of a Qt-based Firefox but nothing happened about this exciting project. I guess we will unfortunately experience the same now :-(
I am happy if you prove me wrong...

It looks like the mozilla 'dudes' require some 'respect' from Dirk. Dirk hasn't proved that he is a capable hacker. There is no evidence that he knows anything about HTML, or web browsers in general. Maybe he is a nutter who would go apeshit if given CVS access?

Hey, wtf I am talking about?!

They are refusing to give access to a top khtml hacker, who knows more about good code than those muppets do (judging by the state of gecko), because they fear he might change the button ordering. OMG.

The fact is Mozilla is entrenched with GNOME 'supporters'. The code has significantly dipped in quality over the last year, and now I know why.

Thankfully Dirk et al have given up on the gecko port and are instead trying to unify webkit/khtml. Much better codebase and hopefully there will be less GNOME 'tards to deal with.

Actually I don't see any problems here. Those people never said that they won't give out a CVS or SVN account to Dirk or Zack, all they asked for is to file in some patches to bugzilla so the officials can verify them and then commit them. Later on they promised to give out the asked accounts.

But then on the other hand... QT support was basicly non existing in Mozilla or the codes have been that old that nothing could be used anymore... So technically nothing could go worse if they would have granted CVS access to Dirk and Zack to maintain this part.

The guy with the Novell brand in his name was offering to help make it happen.

Cause anyways...
DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS
Seems like the Firefox project was acting like it was a privilege to work on Firefox, when really its the project that is privileged to have developers. :)