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.
Post a Comment
Member since:
2008-12-26
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...
Member since:2006-01-04
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.
Member since:2009-01-13
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.
Member since:2008-07-07
Member since:
2008-05-26
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.
Member since:2005-11-09
Member since:2009-03-20
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.
Member since:2005-11-21
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.
Member since:2005-11-09
Member since:2005-07-06
Member since:2005-07-06
Member since:
2006-08-03
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.
Member since:
2005-07-06
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 ;-).
Member since:
2005-07-07
Member since:2006-01-01
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.
Member since:2005-11-21
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.
Member since:2006-06-04
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?
Member since:
2009-07-02
/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 !
Member since:2005-11-09
Member since:2005-07-06
Member since:2005-11-09
Member since:
2007-12-08
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?
Member since:
2005-07-06
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.
Member since:2005-07-09
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.
Member since:2007-08-03
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.
Member since:
2006-12-05
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.
Member since:2006-03-05
Member since:2007-02-12