Dear PlanetKDE/Lazyweb,
I am curious about the future of KHTML in the face of WebKit. Three questions come to mind:
- Why does KDE use KHTML when WebKit is faster, more compatible, etc?
- Why does Konqueror use KHTML as default instead of WebKit?
- Will KHTML be moved out of the main tree?
As far as I can see, it is commonly accepted fact that WebKit is a faster and more compatible engine than KHTML. WebKit was ported to Qt in 4.4, and Qt 4.5 provides some critical enhancements. From these two points, the three questions above naturally follow. If the situation for KHTML was completely hopeless, then it never would have made KDE 4.0 or the present API would be converted into a wrapper for QtWebKit. But this is not the case, so presumably the KHTML team has high hopes for the project. I wonder what the team’s response is to these questions. Undoubtedly they have thought a lot about KHTML vs WebKit and find WebKit a worthwhile project. What’s the deal?
I don’t know the answers, but I can give you an anecdote. I have to use webct for some courses (ugh). with khtml it kinda mostly works, but randomly fails to load or crashes. with webkit it can’t log in (in qt4.4 it failed, in 4.5 it actually crashes konq) but once I log in (with khtml) webkit can navigate the evil site without problems. so, I need *both* engines until one of them stops crashing konq.
I wish I knew why the webkit option randomly vanishes from the menu sometimes.
I should probably put some effort into helping someone fix those bugs, I guess.
Dear Jason,
Three answers:
1. Developers are still developing KHTML because it is their pet project and they like to improve it. And they sure like that they have full control over the project.
2. Konqueror uses KHTML as default, because the WebKitPart is not fully usable yet (it is in playground).
3. Maybe with KDE5 KHTML will be deprecated (obsoleted), or even removed. That depends on how good/fast WebKitPart evolves as a replacement.
1.) The Konqueror/KHTML developers are either dickheads or in secret work for Mozilla to keep Konqueror crappy so that everybody keeps using Firefox.
2.) see #1
3.) Hopefully never. (KHTML should just die.)
Luckily there are rekonq and Arora.
In my personal experience, webkit is pretty slow and horrible (scrolling lags, rendering is slow, javascript execution is slow, etc.). I’ve tested both with arora and the webkitpart. And I use Qt 4.5.
The question should be “when will web developers start testing against KHTML?”.
Dear lazyblogger,
Three answers:
1) Why do you question some people’s motivation on working something specific.
2) Because KHTML was part of KDE when WebKit wasn’t part of Qt yet.
3) Obviously can’t and won’t happen within the API and binary stable KDE 4.x line of which KHTML is part of.
Markus, I’m waiting impatiently for a really usable webkitpart, and I’m not too worried about the devs losing complete control over the browser engine.
Webkit is part of Qt and we depend on Qt for the upgrades of the engines, and webkit version included in 4.4 molstly sucks because of lack of features.
So no webkit in Konqueror until KDE 4.3 is released. KHTML is not going away during KDE 4.x series but we will soon be given choice about the rendering engine.
More important, avoid insulting the team that started the whole webkit codebase and go trolling somewhere else.
All of the points in #1 apply to Microsoft windows. Let’s switch now!
If you don’t like how things are, go code. People like to complain, they don’t like to actually work.
Such closed mind people in the so called ‘free software’ community!
So, following your logic, you should not criticize nor protest against the railway company, because you are not able to manage a railway station?
Who is KDE in your “KDE”? You are KDE, too, if you are on the planet KDE. And your fellow contributors just happen to have fun and do good work with KHTML. Why should they stop? Should there be a drop of KParts because there are other component models? Please do not forget, someone has to do the work. If you want a good working webkit based html kpart, it is up to you to make it happen. And only if it is ways better then what has been in the main modules before, then there is a time to consider a swap of priority of HTML handlers.
Please do not attack your fellow contributors this way. How would you feel is someone renders your endless efforts just useless?
I for one are happy KHTML is live and kicking. So should it be. It means direct access and more control. And some people who have fun doing a first class HTML module.
I asked myself those questions too and i think they’re quite obvious since webkit is being talked about so often these days.
Now KHTML is for sure a nice engine and might as any other become one of the best ones out there.
The one thing i regret is that there’s not much communication from the KHTML/Konqueror devs.
I mean, i’m not part of any “inner circle” of communication of KDE (if there exists such a thing). I read the planet and the dot, and not having any kind of blog relating the progress made feels a bit like there’s no progress made at all…
Now a project like KHTML has surely less “bling” to show off like, say, Plasma but still, i’m sure that these projects could make a little effort in that area.
KHTML is being worked on because we believe in long-term benefits over short-term ones.
Of course, you may be right, it may be somewhat quixotic, since it seems like even supposed Free Software adherents gladly accept the new proprietarization of the web. And, well, what’s the point of a Free & Open desktop if all your applications (and data) will move to proprietary web platforms, to be used only in browsers blessed by these platforms’ owners, with these browsers developed largely at the financial mercy of businesses whose goals directly contradict those of KDE?
Jason, I think you have a flawed assumption that “WebKit is a faster and more compatible engine”. I would agree that Safari is probably more widely used and tested by web developers, but that does not mean that the version(s) of webkit used in qt/kde are the same renderingwise. I’ve played around with webkitpart, which is what kde _would_ use and it is nowhere near as fast or compatible (across a broad scale) as KHTML (in my experience).
And an above poster answered the “why does kde use khtml” bit, in KDE4 there are binary/api compatibility concerns that take precedence over webkit, even if it was superior (which at the moment I believe it is not)
@Andrew ABI isn’t a concern really, KHTML in kdelibs could be made into a wrapper. It probably should’ve been since we knew before KDE 4.0 was released that which technology to use was going to be up for discussion. But even now it could be (though probably not perfectly since mapping to QtWebKit might not be 100% possible).
Anyways see SadEagle’s response, I guess this answers the why.
> More important, avoid insulting the team that started the whole webkit codebase and go trolling somewhere else.
@Skarn you are wrong, the team that started the whole project left KHTML for a long time and now work on QtWebKit, all of them. And this include Lars Knoll and George Staikos, the creators of KHTML, even him gave up on KHTML and went for WebKit.
I speak for myself only, but consider Webkit as a hostile fork of khtml. The saga of khtml/safari/webkit could be a very successful co-opt and kill strategy for those who don’t want a successful and competitive free desktop.
The reason why webkit isn’t available in useful form in spite of the many supposed advantages is that no one will work on it’s integration with KDE if they aren’t paid. Or not enough will. There seems to be no community except users clamoring for it’s adoption.
Khtml has an active developer community, and is actively maintained.
Those things mean much more to me in the long run than some supposed advantage of using an engine that everyone else is using. Come to think of it, I don’t like monocultures either.
Derek
@SadEagle: Can you explain why you think WebKit is proprietary? Obviously it’s available under the LGPL/BSD licenses, so I guess you’re talking about the behavior of Apple?
I was under the impression that it was a fairly open project that had invited the KHTML devs to join it, but I suppose I might not have the full story.
Personally, I use Firefox on Linux because I don’t think Konqueror as a whole is ready as a browser yet, so I don’t have too big of a stake no matter what is decided.
@truther Harri, who wrote the javascript interpreter, still works on it. Possibly others.
Thanks God I still have Konqueror/KHTML. Arora is slow and lacking features, Webkit Part is simply unusable right now, and Firefox is slow as hell in Linux (especially if you use non-default GTK+ theme). Maybe other options are Opera (but it is closed-source) or Firefox on top of wine (http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-firefox).
Why does Konqueror use KHTML? Webkitpart is really in a sorry state, if you want to improve it, then go ahead
Will KHTML be moved out of the main tree? When we have a better alternative…
Webkit is good rendering engine, but so far no good webkit browser for linux yet ..
@Ian Monroe: QtWebkit still doesn’t have a public dom API, so no. Apparently it could be done to webcore (the safari stuff). Or we just wait.
@truther: Skarn could say “active KHTML developers”. Better?
Along with Harri, Germain is another who hasn’t left the project. I’m not actually sure this is a good argument to make.
I think dkite puts it very eloquently.
Well, I think (because I have only heard) that webkit is technically much better engine. I use Google Chrome on my windows machines and I just love it. But. More than Chrome or webkit at all. I like Konqueror. It is such simple, nice, easy to use and still powerfull web browser for KDE, that I can not just use Mozilla Firefox or any other crappy (yes, I see Firefox as crap browser! Sorry fans!) browsers.
I would like that Internet Browser (Konqueror in this case) would allow user to switch HTML-engine easily. Just like konqueror. I have tested the webkit kpart and I did not notice any specific speed up or other feature, so I keep using KHTML. I like to support KHTML because, it is the mother of the Webkit. Okay, so what if KHTML project starter developers switched to Webkit? I just hope that there is enough developers to understand that if everyone jumps to webkit development, we end up in the end to same situation as the Internet Explorer have support for the web standards etc. So, it is better that KHTML is around and keeping competition alive. I do not like either that Mozilla Firefox is now on over 20% share and Opera and other browsers are under 5%.
We _need_ multiple HTML engines, we need multiple different javascript engines and all kind other things. Just like we need multiple choises for applications, Linux distributions and even multiple different operating systems (Linux, NT, SunOS, BSD) to give a better future.
And I do not blame those developers who want to work with the KHTML, but I “blame” those who left it and moved to webkit, after others has done better job for it. It is sad that KHTML feels in these days more a “fork” from Webkit than it is from KHTML. Feels like Webkit is a child who should take its mother when she is old, but instead when the child got famous, he has left the family and moved to other country and all what he does is sending few letters what keeps the mother someway alive.
Mayby the questions should be turned this way…
1) Why KTHML should be forgot?
2) Why shouldn’t Konqueror use KHTML by default?
3) Why we need to support right away the more faster, more compatible etc? If we would do that, why did we supported first place the Mozilla Firefox when all websites were designed to work only with IE? Why we are trying to use Linux with it’s 10% market share when the Microsoft has over 80%? Why we should try to develop a KDE if it was needed to code almost from scrath to fourth generation if we got Gnome Available or other new lightwight desktop environments (LXDE etc)?
Well, the main (original) question might stay, should we change the default Konqueror HTML-engine from KHTML -> Webkit? I say in this condition, NO.
Because reddit.com actually loads in KHTML without causing some crazy ad loading recursion/hang.
If you’re jonesing for a Webkit then use Arora. In general performs much better than Konqueror with Webkit.
> I mean, i’m not part of any “inner circle” of communication of KDE (if there exists such a thing). I read the planet and the dot, and not having any kind of blog relating the progress made feels a bit like there’s no progress made at all…
Well, not every developer is a blogger. But most of them can be found on IRC. Also lots of discussions can take place in mailing lists, I guess. I definitely remember poking some members in IRC about the state of WebKit/KHTML, and then writing about that on my blog (I can give a link, but it’s in Russian)
Konqueror+KHTML+KJS rocks!
Sure there are always thinks, that could work better (on my system flash frames are not shown on every page load).
But there are only very very view sites not rendered correctly with Konqueror 4.2.0 (M$ sites are not made to be rendered correctly). Knowing the fast rendering and smooth scrolling of Konqueror makes the use of other browsers feel like using software from a past century.
Dear developers: Keep on improving Konqueror and keep on improving KHTML! You already did a great job and I am sure you will continue to do so!
And please, solve my flash problems!
I’d like to add a comment as a long time user of Konqueror/KHTML (since KDE 1 it’s been my main browser). The team behind KHTML is doing an absolutely amazing job keeping up with both expanding web standards as well as rendering engine competition. Don’t believe me? The acid3.acidtests.org score in my KDE 4.2 konqueror is 85%, while the current Google Chrome (Windows) clocks in at 79%.
I don’t understand how anyone in their right mind could question what the KHTML team is delivering. Count in the arguments related to monoculture and freedom, and you should be willing to think again.
I hope KHTML gets killed already because konqueror is really dragging kde distros down atm. Google docs doesn’t works with it and a lot of other important websites. I don’t give a fuck if it’s 0.0000001 faster if i can’t really use it without restrictions.
Ah, here they are again: The KHTML fanboys spreading anti-WebKit FUD.
Some here argue that WebKit sucks because the Qt port sucks. Everybody who ever used a WebKit browser on an actively maintained port sees very soon how great WebKit performs. The Qt port of WebKit needs some attention, because it’s not the top priority of Qt Software. That’s where the KHTML developers could help out. However they refuse to do so. WebKit is supposed to be hostile and other blahblah.
If WebKit was so hostile, why is the Plasma team using it and not KHTML? WebKit is such a big win for free software, because unlike KHTML it’s toolkit independent. GNOME and KDE developers work together on dbus and it turned out to benefit both parties. The KHTML team OTOH refuses to cooperate. Now everybody else (the GNOME community for GtkWebKit, the Android community, Apple, Nokia for S60, etc.) cooperates on WebKit and all benefit from it. Just the KHTML/Konqueror team thinks it’s something better than the mere mortals from other projects…
@Markus: calling people “fanboys” is not going to improve the debate. While I argue that the KHTML team could use some better communication, I think that most people see WebKit as “cool because Apple did it”, regardless of its (without dobut) technical merits.
The main issue I see here is that WebKit goes where Apple wants it to go. With KHTML, it’s not that.
@I think that most people see WebKit as “cool because Apple did it”
Hehe, many people think rather opposite. I can’t name single apple product which isn’t crap (maybe except ipods…). However, if webkit is really better then Khtml I will use webkit. It’s Open Source too…
I have to say that _for me_ KHTML sucks donkey balls.
Netvibes, Digg, Google they all work like crap. I think I saw a comment from a KDE developer (I think Aaron) once that some of the KHTML guys kinda refused to work with webkit and therefor I think they are holding KDE back quite a lot. They are free to do whatever they want, but that is the truth the way I see it.
If you don’t acknowledge the fact that for most normal users, that just want all websites to work like they were intended to work, KHTML just sucks, you are living in denial.
Well Konqueror has never given me a good impression, KHTML or Webkit (I’ve tried both). Both are slow, both have noticeable font size glitches, and Konqueror just doesn’t have the extensions or configurability I require for my web browsing.
Mozilla Firefox for me.
I’ve been happy with Konqueror and KHTML for quite a while now.
I’m not saying it’s perfect. But I still prefer it over any other browser (from Firefox to Opera, Arora etc.) and am happy it’s there.
@Markus
Qt port of Webkit sucks? Then DO it yourself! Don’t ask other people (KHTML devs) to do what you want. The KHTML guys like to play with the rendering engine, not porting a rendering engine from one platform to other platform(s). Dictating others what to work on is simply ridiculous, you even never pay a single cent for them.
I’m not anti-Webkit, but Webkit solution for Linux is not ready (yet). And you are very welcomed to help. If KDE is ready to just use Webkit and dump KHTML forever, then it will just happen naturally.
Firefox rocks, but unfortunately only on Windows. It makes sense, since most of FF users are from Windows, so it is logical to give more attention to Windows FF. But still, I have to keep FF in order to view one or two websites which is broken in Konqueror/KHTML.
OT but related: Does anyone know how the QT Firefox port is coming along? I couldn’t find useful info on the net on that topic.
Although I use linux on most computers, I’m currently viewing this page on Google Chrome under Vista because of a lack of a certain driver in Linux. Chrome is truthfully:
1. About the same speed as Konq.
2. Less configurable than Konq.
3. Much more compatible on three or four of the most frequent pages I visit. (Google Docs, ATWOnline, TSN.ca immediately jump to mind)
4. Surprisingly awful at opening a tab in the background (it often locks up the rest of the browser while loading a complex page.)
I realise that’s not a KHTML – WebKit comparison, but if Google can’t make WebKit work that much better, I’m not sure I see the logic in dropping KHTML just yet. Arora and ReKonq are fun to play around with too, and anything with WebKit to me is still of KDE pedigree anyway, so I wouldn’t mind switching if it came to it, but I just don’t see the rush.
If I have a look at what KDE got for dropping its own printing system and using some external, i.e. Qt’s, I would really make sure that webkit is up for the job of replacing KHTML in all its uses within KDE before even thinking about dropping KHTML.
And what about bugs?, reporting them at Qt’s site rather than KDE’s and relying on them fixing them and the user having to wait for the next Qt release? Sounds bad IMHO. Especially if you look at how Qt-devs took part in handling/fixing printing bugs.
@peter: phonon seems to handle being shared between qt and kde just fine, though. no need to wait for a qt release there. and khtml devs were repeatedly offered commit access to qtwebkit… and qt is making moves to open up its repos more now that it’s lgpl…
you’re right that it doesn’t make any sense to make webkit the default before it’s ready, though. as for dropping khtml… well, that seems kinda silly, because it works and there are people who like it. when dolphin was created, file management wasn’t dropped from konq.
Long live KHTML!
KHTML and Opera engine are last browsers truly incorporating web standards defined by W3C. The rest is only doing what they like or what is pleasant for them. Two years ago I made study of some JS code on popular site. Compared it with Konqueror implementation, Firefox implementation, Internet Explorer implementation and W3C docs. Only Konqueror was truly, to the letter, following “common” standards. The rest was giving it a finger.
To the people praising Chrome: this is EEE in Google way. To the rest: be afraid, be very afraid.
Looks like this flame heats up from time to time:
http://zrusin.blogspot.com/2007/10/khtml-future.html
Instead of flaming: what about discussing, planning, roadmapping, taking decisions?
To me as a user it seems that regarding some topics there’s some lack of guidance in the KDE Project.
Haven’t used konq for a while so I tried it just now (4.2).
Went to maps.google.com, konq froze for about 45 seconds, then it completely failed to work, at all. Can’t even drag the map around or see any of the controls.
Works in Firefox, works in Arora (and man, arora is stupid fast to load).
Yes webkit still has issues, but at least it doesn’t completely fail on some really important sites (that used to work in the kde3 series of konq mind you). Konq just can’t stay competitive against that.
Leo S: for every website failing, one could give another one failing in the “other” browser. But just to talk about google maps, it works fine in trunk, and I don’t remember when I had problems with it.
Regarding webkit and khtml, I can perfectly understand the KHTML devs and support them. Webkit is something that went against the spirit of open source and the result is what we see now: several forks, variants of the same codebase, which once was khtml. There is no “standard” webkit, there is a version in Safari, another version in Chrome, another one in Qt and so on. Each with different sets of features, bugs. Now on which one should KDE depend on? Well probably on Qt’s, which when 4.4.0 was released had bugs that were not present in KDE. 4.5 comes with an updated version, but due to the different politics behind releasing a Qt or a KDE version, there are high chances that Qt will always have an older snapshot of webkit. While khtml can be improved quickly, if we have enough motivated developers.
), but IMO that is the right way to go for KDE.
What is missing in KHTML imo is an API somewhat similar to QtWebKit. I don’t know why Plasma or Amarok chose webkit against khtml, but I can imagine it was because of the nicer API. So there is room to improve it (Maksim knows how many bugs I reported that aren’t fixed
@Andras: _I_ haven’t encountered a website that failed in Firefox lately. (Like the last 3 years!)
_For me_ that is what a browser should be all about. You know _browsing the web_ without fail.
IMNSHO webkit based browsers are getting there (or are there already). KHTML not so sure. It seems like it will always play catch up with the web of today. But that is something the KHTML people will never admit.
Am I the only one to notice that Konq/KHTML does not load GMail GUI v2 at all ? This is the main reason why I do not use it. I need all my GMail functionalities, including the GTalk integration. If it does no work on a browser, then this browser is a no-go for me (actually, the webkit-part does not render it either… and Konqueror is overloaded with functionalities I don’t need, such as being an all-viewer. I want my browser to be only a browser, don’t want it to switch mode unexpectedly… but this is a very personal point of view).
So I use Firefox (not opera, because I cannot move the bookmarks bar in order to save space), even if it’s a PITA.
@Kragil You haven’t found a website that fails in Firefox, because at this point it is a monopoly. cf Flash working only under it in linux. You can always stick with Expolorer too.
@Diego Most of those “original” people there haven’t made an actual commit to the webkit or khtml codebase for a long time. Go check the stats.
@Peter: Yes. Just watch some of the frustration on irc.
If you want gmail to work, it would help some to complain directly to google. Sort of like politics.
> Am I the only one to notice that Konq/KHTML does not load GMail GUI v2 at all ?
It actually does. Change the user agent to something Firefox in Konqueror and it will work like a charm. Google just ignores Konqueror’s capability otherwise. Selection by user agent instead by actual capability is a disseas on way too many ajax driven sites.
Many times it’s not the engine itself but the browser that isn’t supported. I for one agree that webkit should not only be the main engine but the only one. Not because it’s better, but as of right now it is average, but because it’s supported by way more developers which means it would be a much better engine to support. Think of it this way. If we had 2 linux kernels and 90% of the distos supported one and then 10% supported the other one which one is going to improve faster. Yea the one with 10% might be better now, but in a year I bet you couldn’t say the same thing.
If the developers switched over and got QTwebkit up to speed and then helped develop it further it could be a great rendering engine and would be great for all web developers, who would not have to install 10 different browsers to test all the backends. Of course most times nobody thinks about the guy on the other end who instead of build awesome new features for websites all day, has to test every change he makes to his website on 10 different browsers, and ends up creating hacks to fix 3-4 of them and leaves one of them broken.
My #1 problem though is that konqueror could be such a better browser if it only supported a better feature set. I’m only asking for a better UI for web browsing, a real add on section with GHNS support and ad block support that updates for easylist, like most browsers, that and the ability for it to collapse the sections between ads.
Oh, for christs’ sake…
FORK WEBKIT, ADD WHAT’S NEEDED AND CALL IT…KHTML.
DONE.
Everyone wins. They started the project, there’s nothing disingenuous in re-claiming it for its original purpose.
>It actually does. Change the user agent to something Firefox in Konqueror and it will work like a charm. Google just ignores Konqueror’s capability otherwise. Selection by user agent instead by actual capability is a disseas on way too many ajax driven sites.
No it does NOT work… If I’m talking about that, it’s because I’ve tried… If you switch the user agent, the load bar appears, loads very slowly, and you get a white screen at the end, nothing more. I never got to the inbox. KDE 4.2 here…
To the person who claimed that Konqueror works with GMail with a user-agent switch, either they have a non pulbic build of Konqueror, or know something about user-agent switching that I don’t — it does not work for me, and I use GMail heavily to access mailing lists. I hate Firefox on Linux, but Konqueror isn’t good enough for my day to day user.
Yes, doing user-agent filtering is dumb, but that doesn’t change the fact that WebKit has evolved faster than KHTML. It also doesn’t change the fact that no web devs are testing against KHTML.
Web devs test against IE because they have no choice. They test against Firefox because that’s what they use. The may test against WebKit because its fairly easy to do, and its end result doesn’t differ from Firefox too much. But I know of no one testing testing against Konqueror.
At this point KHTML is a wasteful allocation of resources. Accepting that the people working on it should not stop their hobby just because I don’t find it useful or necessary, it does not mean that the KDE project should stick with KHTML.
Basically, I would like to not have to install Firefox on a fresh install until I need to test across browsers.
@Blooper: I was exspecting that. Lame Explorer arguments are lame. Firefox a monopoly .. yeah right.
I love konqueror, except for browsing. It’s a pity that there’s _no_ really highclass browser for KDE. I use a combination of FF3.0, 3.1 and Opera but none of them are really satisfying. Konquerer woth KHTML oder WebKit is IMO not productively usable at the moment. My biggest hope is that the integration of FF in KDE will come some time. (Especially 3.1 which has a nice new JS-Engine, like the new WebKit from Safari 4)
I really appreciate every work who is done for making KDE better, but I don’t think that KHTML ever has a chance that it will be enough widespread. And that is necessary, otherwise there will be no webdesigner who cares about KHTML/KJS. But thanks anyway for KHTML it’s nice to play around with it.
@Datschge
1. I don’t believe anyone is questioning anybody’s motivation or right to work on what they want.
2. Just because KHTML was ‘there before’ in KDE (a rather childish argument) it does not preclude looking at other options.
3. Stop trying to make it sound like we’re stuck with KHTML. API stability is irrelevant here and it does not stop WebKit usage. KHTML simply has not gained any traction at all amongst web developers and testing as an engine, and as such we’ve got to ask ourselves when we will get a well used and well supported KDE based browser.
@Segedunum:
Thanks for your point 3. Exactly what I meant, really a key!
@Segedunum
3. Amazingly enough, KDE follows rules on API and binary compatibility. You can’t say it is irrelevant here. This stuff is part of the base libraries.
If you want to go code renderers, and frameworks for renderers, feel free. Ditto for integration with KDE. Otherwise, complaining looks childish. It won’t get you a magic pony. There are less volunteers working on KDE-webkit stuffs than there are on khtml stuffs. So feel free to join them. Coding will get you somewhere, playing fanboy will not. (You can also go and file useful bug reports!)
I invite people to reread dkite’s comment above, and also SadEagle’s (he’s one of the developers). Andrew Stromme’s is pretty good too.
I agree with SadEagle. (@Matt: it’s not WebKit which is proprietary, it’s the web apps – and non web app sites work just fine in KHTML.)
I think what we really need is a wrapper around KHTML which claims to be QtWebKit, not the other way round.
QtWebKit does not even use actual Qt widgets, even the scrollbars are fake! (I know because I had to fix the widget style I’m maintaining to support QtWebKit’s fake widgets.) They reinvent the whole code of the widgets and only use Qt styles for drawing. And not all stuff is even drawn with the style in the first place (some stuff is drawn either in hardcoded code or with QWindowsStyle hardcoded).
And for those who say “WebKit is great, it’s the Qt port which sucks”, well the Qt port is what KDE has to work with, if it sucks, WebKit sucks for KDE.
@Blauzahl
Point 3: Yes, it does follow API and binary compatibility in which case KHTML is going to be there throughout the lifetime of KDE 4. However, that doesn’t preclude WebKit usage and make KHTML usage a given.
@Kevin
No one cares, quite frankly. Users care about what sites display with their HTML engine and developers care about not having to test with yet another engine they just don’t care about. Bringing marginal technical arguments in here doesn’t change the bigger picture.
In order to get a working engine for KDE and Qt users there was basically two options – integrate Gecko or look to WebKit. The people working on Qt chose the latter, and those were people who started and worked on KHTML in the first place!
[...] ist ein schlanker, in ANSI C geschriebener Webbrowser. Als Parser kommen hier weder Gecko noch WebKit, sondern Hubbub zum Einsatz, die zwar HTML 5 kann, allerdings schon die einfachsten CSS-Anweisungen [...]
Hello everybody,
is it possible to turn Webkit in Konqueror as default rendering engine? Now, when I want to use Webkit I have to switch it manually on in View menu.
Very cool post.keep em coming.