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 the
KDE 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.
Anyone wishing to join the effort should contact the developers on the
kfm-devel mailing list. Source code is accessible in KDE's Subversion repository.
For press queries about this and other KDE announcements see the KDE press contacts page.
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?
Did you click on them? They're quite sharp, minus the antialiasing on the text which is supposed to make it look a bit less sharp I guess. :-)
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?
Just so I understand, you are "concerned" about the ?fonts? in a pre-alpha port of a web browser to a new platform? It can't render flash yet either. OMG!
Are you looking at those screenshots on a CRT? The screenshots are using subpixel rendering which definately will look odd on a CRT ...
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 don't like the fonts either, but i'm sure its a setting, just like it is now... you can configure the look of your fonts ;-)
You're looking at a screenshot of subpixel anti-aliasing, not actual anti-aliasing.
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.
I'm using full hinting here, and the screenshots look actually very painful to my eyes. It's as if they were horizontally blurred
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.
The font is terrible bad. I have a look on different systems with different monitors. Pls check your eyes.
you first :)
that "sharpness" seems to be of nvidia sharpness settings. not just fonts but all elements look sharper (white contrast around black icons, fonts, elements).
Are there plans or interests to have it run on Windows?
Because of the depency on Qt4 only it should not be so hard to port.
All of KDE 4 is intended to run on Windows, so I'm sure it will be.
Hehe,
not all of KDE, but most of the apps and i.e. this for sure.
E.g. the WM will not run on Windows as Windows has already a WM.
Sounds like Webkit support will make support easier and will free ressources.
Please, oh, please tell me this will make Konqueror have good support for AJAX pages. If so I might just have to learn C++ and help out X-D.
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 :/
BestBuy's site works fine here (Konqi/KDE 3.5.3), though alpha.qunu.com didn't load right for me. Also the 'J' in AJAX is 'JavaScript' ("Asynchronous JavaScript and XML" is the whole acronym).
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.
Did you even check to see if the bug you mentioned was fixed or not ?
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 :(
I'm in the same boat. I pretty much only use Konqueror for the kde: and qt: shortcuts now or when I'm doing something like uploading a file (KDE's file dialog is so much easier).
http://alpha.qunu.com/
in Konqueror-3.5.3 I get
Fehler: http://alpha.qunu.com/qunu.js: ReferenceError: Can't find variable: HTMLElement
[...]
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!
But we are lucky - there is a simple workarround:
http://www.codingforums.com/archive/index.php?t-60406.html
Ajax problems are manly caused by small javascript-cross-browser-differences. But there are well done libraries like http://www.mochikit.com to fix this.
regards, Jan
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.
why Konqueror is not compatible with gmail?
Have you tried setting a different user agent?
One of the widely known issues ith GMail is that they have a broken browser check and seem to not detect capable Konqueror/KHTML versions correctly.
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?
Thanks!
Just going out on a limb: since KSVG2 is based on top of KDOM2, and KSVG2 is being ported to Webkit, it would make sense that KDOM2 is as well.
I am not sure, however.
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.
In general, all code concerning XML & HTML is chaotic. I fully understand anyone who can't track it(I don't, I didn't know about unity until now). There's KSVG2, Patternist, KHTML, KHTML2, KDOM, WebCore, and the list goes on.
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.
For those interested, Patternist's API documentation is here:
http://patternist.sf.net/documentation/API/
Cheers,
Frans
(KDOM/Patternist developer)
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!
Hi,
It is all a bit hard to explain :) This describes our experiences best:
http://lists.kde.org/?l=kfm-devel&m=114099614807147&w=2
Please drop by in #ksvg sometime if you need more info.
Cheers,
Rob.
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.
Frans
Some more comments:
* 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 :)
Frans
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...
One of the reasons why the gecko/firefox/Qt port failed was the stubbornness
of the mozilla ppl wrt giving cvs write access to some kde devs.
c.f.:
https://bugzilla.mozilla.org/show_bug.cgi?id=265484
This eventually made the interest in a Qt-port of firefox die, unfortunately...
Probably the fear that a 100% Qt-port would be a much better experience than
the default gtk2-port was one of the reasons...
Actually:
https://bugzilla.mozilla.org/show_bug.cgi?id=297788
That is an amazing bug report.
And here was I thinking it was another OMG-Qt-is-not-truly-Free kind of issue.
Id love to have a Qt fox
I love their word "bureaucracity". It sums up the situation nicely.
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 most Vocal guy on that list had a NOVELL brand in his name....
The point is that Dirk is already a proven hacker.
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. :)
"The most Vocal guy on that list had a NOVELL brand in his name...."
The guy who had NOVELL was actually offering to help.
"They are refusing to give access to a top khtml hacker.."
Why not just fork out?