Whenever I use KDE, the part I dislike the most is the rendering engine used by Konqueror, called KHTML. KHTML just doesn’t render pages as smooth and as well as Gecko and the KHTML fork WebKit, up to a point where I find Konqueror unusable as a web browser. However, work is underway to replace KHTML in Konqueror with WebKit, but according to KDE developer Adam Treat, this is a futile effort: Konqueror is too KHTML API specific.
I’m not the only one who dislikes KHTML’s rendering in Konqueror, as the call for WebKit integration into Konqueror is a strong one. It makes sense, too; WebKit is a fork of KHTML, and over the years, WebKit has simply become the better of the two, with major backing from companies like Apple and Google, among others.
Adam Treat, who works on the QtWebKit KPart, and has worked on its integration with Konqueror, now explains that Konqeuror is simply too tied into KHTML to even work properly with the QtWebKit KPart. “Plumbing the sources of Konqueror I learned a nasty secret: Konqueror is highly KHTML API specific,” Treat details, “Konqueror has deep integration with KHTML that goes far above and beyond the KPart API. Creating a QtWebKit KPart is woefully insufficient for the purpose of providing anything more than a basic HTML viewer.”
That’s not good enough, obviously. He further explains that if the KDE community wants a QtWebKit browser, they better look beyond Konqueror. “Otherwise you are left with two hacky solutions: make a QtWebKit KPart that is API compatible with KHTMLPart OR migrate Konqueror source to make it less dependent on KHTMLPart,” he says, “The former is not going to be fun as the KHTMLPart API is not refined or polished and highly KHTML specific. The latter can only be accomplished with a lot of work set aside for refactoring or through nasty ‘#ifdef KHTML callThisWay() #else callThatWay();’.”
If you don’t like KHTML, then there are two solutions if you’re running KDE: Firefox with KDE integration, or a proper WebKit browser written in Qt. I’m personally no fan of Firefox, so the latter option seems more attractive to me. Such projects are already under way in the form of ReKonq and Arora.
There are several blog posts about the khtml/webkit saga recently, which you saw if you read planetkde:
http://planetkde.org/
Here they are for the lazy:
aseigo: http://aseigo.blogspot.com/2009/07/webkit.html
Actual khtml dev: http://vtokarev.wordpress.com/2009/07/01/being-a-khtml-developer/
(that one makes an interesting point – why should he be working on webkit for free, when there are so many paid developers doing the same thing for pay?)
http://blog.gwright.org.uk/articles/2009/07/01/qtwebkit-vs-khtml-ag…
http://darktears.wordpress.com/2009/06/30/my-only-blog-post-about-k…
This post started it all:
http://www.kdedevelopers.org/node/3995
I have to agree with some comments that the KHTML devs are actually hurting KDE as a whole.
Complex web apps will never work in KHTML and giving people the illusion that that might change is bad. KHTML is a dead end.
You can’t blame KDE for trying to build a full desktop environment with a web browser and everything, but you can blame the distributions, they pick the defaults for users.
I find it very funny that one of the main arguments for KDE was/is reusable code. After KDE4 I think we can safely scratch that argument.
Edited 2009-07-02 12:37 UTC
Oh This is open source forum …
but Linux distribution = bundled software..
EU..Are you looking into these bundled distros…..
No. because for how much you can sue a distro???
The problem you speak of is the MS monopoly for desktop PCs. As KDE does not have a dominant position on the desktop market it can ship a bundled browser. The same goes for Apple by the way.
If KDE decides to move across to Webkit, they need to at least continue to support KHTML.
I will not use Webkit. Its biggest single developer is Apple, and Apple does not have a good track record for writing secure software. Apple’s operating system has well-known design flaws that cause worrying security problems; as they are design flaws they cannot be fixed by “a patch” without breaking application compatibility.
I also have to put my hand up and say that KHTML currently works for everything I’ve tried it on.
Care to enumerate some of that track record?
They had two vulnerabilities in WebKit that allowed that one guy to win the Pwn2Own contest two years in a row. That’s a HUGE number of vulnerabilities, especially compared to historically secure platforms like Internet Explorer.
In all seriousness, the WebKit team is pretty good at applying patches that people send in, but they have very little control over Safari’s release schedule, since that depends more on Safari’s proprietary interface and Apple’s marketing schemes.
Any open source browser effort that uses WebKit is free to perform its own security vetting.
You better include Opera, Firefox, IE7/8 and everyone else in those exploits.
since it was a Flash vulnerability.
Why? It was made perfectly clear that those came about because of the ease with which Safari and the Mac allows you to assume certain things.
Correction. It was a vulnerability in Safari on a Mac, with the Mac being as helpful as possible in the process.
I installed Google Chromium on my eee PC 701… the speed is incredible, it makes firefox eat dust. And it works much, much better than Konqueror, or QtWebkit.
I do not mind it is a gtk app, it behaves like .. well like itself, you will only notice gtk on open/save dialogs.
But anyway, KDE should drop KHTML, it is very outdated, webkit will be the best html engine very soon, it not already. Those who fear apple seems to have little knowledge of the webkit organization.
Hooray. The penny has dropped. Sort of.
If Konqueror and KHTML were up to the job then all this furore about getting a decent and workable browser in terms of viewing websites out there reliably would have been sorted ‘years’ ago. They clearly aren’t and never have been. Funnily enough, it’s why all the sensible people who actually started KHTML, like Lars Knoll and George Stalkos, seemingly moved on and started working with QtWebKit. That’s no reflection on the effort the KHTML guys are putting in, but it’s a question of getting something that works reasonably.
I’m really not surprised at all that Konqueror has turned out to be more KHTML specific than anyone thought, and I’ve found Konqueror to be a functionally poor browser for a very long time. Certainly as a web browser it’s high time it was just put out to pasture and a browser built for the purpose of real-world browsing with a decent framework, perhaps based on Arora as a starting point, where plugins and various other things could just work well or at least have a fighting chance.
Anything less than that is just hurting all of the good groundwork that has gone into KDE 4. Applications, applications, applications – and the big one of them is a working browser that people can browse the web with. Yep, even on Windows ;-).
With such a mess on their hands, why not port an existing code base. It seems like chromium is a prime target for a proper QT port. Make the UI look like Konqueror, add the moniker, and be done with it. Why bother with obsolete code?
Konqueror is much much more than a webbrowser, for better or worse, its more a shell for document viewers. It uses KIO to fetch documents and then KParts to show them in various ways. Meaning I can view a pdf in konqueror as if it were a slimmed down version of okular, the kde document viewer (pdf, dvi, etc). When you click a link to a txt file it opens the text editor/viewer part, same as an image, video, etc etc. While nice in some aspects its really an app that tries to do too much and does none of them especially well.
The best route KDE can go is to go the dolphin route, make an application, that while still highly integrated, is much more web browser centric and tries to be less of a jack of all trades like konqueror.
Safari renders PDF via Preview.app as a Service in OS X. The same goes for images, etc.
There is no reason Qt 4.5/4.6 can’t help in the Services department and allow that interaction being lightweight for a non-Konqueror/WebKit compliant browser.
AS you noted, Dolphin is the File Manager. Slow as hell, but the file manager nonetheless.
Glad I’m not the only one who’s noticed the “slowness” of Dolphin – I prefer Konqueror for file browsing any time.
Having said that . . . actions initiated in Dolphin like moving files and stuff execute fast enough, it’s just that the UI is so slow, like right-click menus and previews.
Could anyone explain to Mr. Sixpack here in Korea why this is so?
/me is wondering WHEN (or if ?) the webkit guys are ever going to start implementing mathml support into webkit.
The argument that there aren’t that much mathml webpages is irrelevant as Webkit isn’t a webbrowser, it is an engine that is used by huge projects that could profit from it, like
Safari and os X (Apple)
Android/Chromium/Chrome (Google),
and by zillions of very various apps that use it to display stuff
http://trac.webkit.org/wiki/Applications%20using%20WebKit
Come on Webkit guys ! Firefox, opera and internet have been supporting that standard technology for years…
There are some opensource engines that can render it and that you can use for inspiration…
Yet the webkit mathml projects has stayed in the planing phase for the last three years….
Damn !
MathML is the most horrid way to create mathematical formulas.
I don’t think the idea was ever to use mathML to write formulas by hand. You use whatever tool you prefer (be it a GUI tool or a markup language like TeX) and then some software translates that into MathML which is easy for viewers to render.
I guess. Might as well just have a backend latex compiler.
Well, that sucks if it’s accurate. The browser is arguably the single most important program on a desktop today, and it bugs me that it’s also the only non-kde app I use on my desktop. I keep hoping the webkit kpart will improve, because it seems ‘so’ close to being usable. And khtml/kjs….sorry, they’re just not an option for me. Slow, incompatible, and not seeming like they’re going to be changing that any time soon.
Like someone above, I’m using chromium on linux right now because that pre-alpha is actually better at rendering pages than konq is. And that’s a pretty sad statement.
I don’t want to seem like I’m not grateful for all the hard work that’s gone into khtml. It got us to webkit in the first place. But it’s clinging to a dead horse at this point.
Is there any work going on right now in making a kde (not just qt) based browser using webkit?
I know it sounds naive of me but if the problem is that Konqueror is too dependent on KHTML then the solution is to rip out that portion relating to KHTML so that it is re-written to make webkit calls or better still, make it so that the calls are to an abstracted layer which allows Konqueror to be blind to the underlying rendering engine.
What ever the case maybe it seems that KDE developers are grasping at straws; if Konqueror is too dependent on KHTML, then rip out that part of the code and re-write it making calls to webkit. It isn’t as though they’re adverse to the idea of throwing out large chunks of code given the 4.x fiasco.
It depends on what “too dependent of KHTML” means. If it means, that there are 10 small classes where there are deep dependencies on KHTML, then sure. If it means, almost every part of Konqueror has deep dependencies on KHTML, then no. If this is the case, then your approach would the equivalent of making a plaid shirt one colour by cutting out all the non-red fragments and replacing them with red patches. Sure you could do it, but you’d end up with a shirt that was more patches than shirt. There comes a point when you either have to accept that you have to accept legacy for what it is, or dump legacy and start from scratch.
I don’t know what’s the case here, but even if the decision is to keep legacy, this doesn’t have to be bad. It could be just another case where the The Bolden Rule (i.e. “If you can’t fix it, feature it.”) can apply. Okay, KHTML isn’t as extensive as Webkit. That’s a feature. It’s not supposed to be any more than elinks is supposed to be anything other than a text mode web interface. Using the Bolden Rule, KHTML can focus on being more secure and lighter and even included desktop specific features.
The comment that Konqueror is too dependent on KHTML has been called into question:
http://lists.kde.org/?l=kde-core-devel&m=124654914508070&w=2
(for everyone who doesn’t follow KDE development: David is usually bang-on when it comes to technical matters, and I’m inclined to trust him on this).
I wouldn’t be at all surprised to see that some of the web-specific plugins (the DOM-viewer in particular) being KHTML-specific, though.
I believe that KDE team should focus on KHTML development further, as KHTML is the only web rendering engine that:
1. isn’t totally controlled by any corporation (which is a kind of risk itself);
2. is good enough to render most web sites correctly (excluding heavily-AJAXed ones and other ugly pieces);
3. is opensource.
When KHTML is good enough to be usable for as many sites as Google Chrome now is Konqueror should get refactored leaving user to choose the web renderer KPart from those based on KHTML, QtWebKit and XulRunner.
Diversity is a good thing, anyway.
P.S.: Still I wouldn’t bet on KDE recovering from major upgrade they had. Too much both users and developers gone.
Where do you get the weird idea that there are many developers gone? More than the usual churn you have in any volunteer community?
What’s up with th KDE comment?
That’s gotta be an unsubstantiated claim. I mean they gained Nokia working on it now.
Ya big crazy
Edited 2009-07-07 02:27 UTC