I've read Harri's blog about WebKit and I figured it makes sense for someone to respond. First of all I liked the blog, It was full of drama, action, despair, marketing and bad and good characters. Which is really what I'm looking for when reading fiction.
Especially the part that mentioned QtWebKit as an irrelevant fork of KHTML sources. That was awesome. It's the kind of imagination we need more of in the blogosphere. For the purposes of the point Harri was trying to make, which I think was "no matter what's the reality, our ego is bigger than yours", it was a well suited argument.
Describing the WebKit project as a fork of KHTML sources is like calling GCC a fork of EGCS, or to use a more popular analogy it's like calling chicken a fork of an egg. If you want to talk about forks then technically nowadays KHTML is a fork of WebKit. Not a terribly good one at that. It's real easy to back that statement up by comparing the number of submits to KHTML to the number of submits to WebKit. In fact that comparison is just embarrassing for KHTML.
I also found it funny that people like Lars Knoll, Simon Hausmann, George Staikos or myself are not part of the KHTML team. "We are the 'KHTML team' (except KHTML's author and ex-main developer Lars who's one of the biggest supporters of WebKit now and other people who used to work on KHTML but now work on WebKit as well... but they were all ugly... honestly!)" you can go make shirts with that.
We're working on WebKit now hence we're not KHTML team members. Any KDE developer who works on WebKit (hey, Niko, Rob, Adam, Enrico...) is automatically dissociated from the KHTML team.
The fact is that there is more KDE developers contributing to WebKit than there is KDE developers contributing to KHTML.
So since there's more of us, I think technically that means that we are the official KDE web engine team. KHTML team, we would love to work with you, the fork, but you're kind of a pain in the butt to deal with.
Which is ok, because like I mentioned a number of times KDE community lives of the "who does the work decides" dogma. And ultimately the Apple guys, the Trolltech guys, people from George's company who work on this stuff full-time and tons of Free Software contributors working on WebKit do much, much more work than people do on KHTML.
On a more serious note, let me explain a very important point: bug for bug compatibility with the latest Safari would be worth much, much more to KDE than any patches that are in KHTML and haven't been yet merged to WebKit could ever be worth.
Web works on the principle of percentages - web-designers test their sites with engines that have X% of market reach. Konqueror with stock KHTML isn't even on their radar. WebKit is. Having web designers cater towards their engine is worth more than gold to KDE users.
And if you care more about some personal grudges than the good of KDE, that's also OK, because we, the official KDE web rendering team will do what's right for KDE and use WebKit.
37 comments:
nice comments, if KHTML is headed to more WebKit compatiblity it would be great!
personally, i use Konqueror more than all other browsers combined, and so far, there's only one thing I care about but doesn't work immediately with Konqueror: google apps.
so, on Linux i use Firefox for them (on mac, Safari works great), except for GMail, which works perfectly on Konqueror... if it set it to pretend to be Mozilla, but not Safari weird, eh?
Yes, much more work is being done on Webkit than KHTML. I'm sure Webkit is ahead in many more areas than they are behind in. But there is still no Webkit for KDE (kpart or such), so none of that matters. Until someone from Webkit steps up and does the KDE integration work that KHTML already has, KHTML is still probably the better choice for KDE. So you can't really call yourself the official KDE web engine team, as there is plenty of the "web engine" bit, but precious little of the "KDE" bit.
So ... how does that fit in with the fact that you haven't actually made a commit to KDE's SVN repository since March 2005, i.e. have had in fact no hand in keeping web browsing working for KDE users in that time frame, or much else really?
Sonnet / Mozilla-Qt / all the shit you start and not actually maintain. Its OK. But stop pretending you are maintaining anything in KDE, because you don't.
Anything you start just rottens here and there.
Some strong emotions here
I hope the kpart for qtwebkit gets completed so the users can choose between KHTML or Webkit and development can continue on both. Both have advantages and disadvantages, let the users decide which they would like to use.
Whoa. Just yesterday (after a long time of quietness) I mentioned on some IRC channel that it's going to be an interesting struggle when Qt 4.4 comes out and includes WebKit.
And now this... Harri pulling off a controversial FAQ in the Commit Digest and on his blog, and you pulling off an even more controversial reply. This is gonna be soo neat to watch!
Let the battles begin! Whoo!
(For reference and bias declaration, my hopes rest more on QtWebKit than on the original KHTML. Adam is always right, and this one is no exception :D )
Zack,
You make a good point about the value of WebKit's market share, but mocking other KDE developers is counter-productive and ultimately damaging to us, the poor KDE web browser users.
If you disagree with Harri's comments then by all means air a different point of view. But please, hold the melodrama for that bodice-ripping novel you are working on.
I was pretty sad about the Webkit thing actually. I'm really sad that I will be stuck running Firefox until people come together (for google apps); But that's how it is.
You put the 'mmmmmm..' in melodramatic!
Do you code in a tower with a raven on your shoulder? :)
Zack, you cannot deny that the people you mentioned working on WebKit haven't done all that much for KDE recently. I guess Simon has done some work on a so-called WebKitPart, i.e. a KPart of WebKit. That definitely counts, but apart from that? Many to all of the people working on WebKit that you mentioned are doing that work as part of their non-KDE day job and I don't see them doing much specifically for KDE.
That being said, I still hope that WebKit will be used in Konqueror purely for practical reasons. Sucks for the KHTML developers - c'est la vie.
All in all both sides are not really the selfless fighters for KDE and we should pick what works best. Worst case a bunch of patches to WebKit needs to be maintained. Yuck.
I think one should start a browser project and like happened with Dolphin it could come to replace Konqueror.
If my C++ skills were good enough I would do it myself.
If there is going to be a punch up, could one of you dosy khtml turnips waddle out to New York so I can do my bitch slapping part.
Technical merits decides all, and I am vested motherf#$%ers
web-designers test their sites with engines that have X% of market reach. Konqueror with stock KHTML isn't even on their radar. WebKit is. Having web designers cater towards their engine is worth more than gold to KDE users.
As a web developer, I must agree with you. What those big companies did for WebKit is putting it on the map, which means it gets tested for. KDE shouldn't get left behind just not to throw out old code. Kicker is someone's code and it still got booted.
As someone mentioned, a KDE4/WebKit-based browser (but only that, a browser) would make a great project, maybe with a possibility to mimic Firefox, Safari and Konqi, not (only) with looks but with usage (shortcuts, mouse actions etc.) I'd use it for sure.
Really sad this has to come to a fight, but to be honest, it was more or less what I expected to happen. Unfortunately for the KHTML people, right now I use Firefox just because gmail doesn't work properly in Konqi (even if I set the useragent to Firefox). I don't have a choice in that regard - mostly of course because of the marketshare KHTML has (or doesn't have).
So, I would welcome WebKit. Even if I lose 1 or 2 features (I'll most likely gain more - a working gmail, for one).
To all of you guys commenting who only count "lines-of-KDE-code" and exclude all the "generic" code that is not tightly coupled to KDE, I'd like to ask you to please wake up and smell the freedesktop spirit of writing generic code which can then be used by whichever GUI (KDE, Gnome, whatever) you like... Working on generic code doesn't mean you are not contributing to your-favorite-desktop, it means you're contributing to alot more then just your own favorite!
Cheers from a dude who prefers Gnome and looks forward to the days of the Gtk+ port of WebKit being more mature...
//fatal
As someone mentioned, a KDE4/WebKit-based browser (but only that, a browser) would make a great project, maybe with a possibility to mimic Firefox, Safari and Konqi, not (only) with looks but with usage (shortcuts, mouse actions etc.) I'd use it for sure.
With the Qt Port of webkit, it's not that difficult to get a basic usable browser working. Here is the result of about one month of programming. I admittedly only sporadically got to code so it is barely usable, but its just the beginning: http://www.informatik.uni-bremen.de/~momesana/mob-3.ogg
@momesana,
nice work :) Maybe you should publish your project and get some more people involved
Hey I've got a great idea, how about scrapping khtml and webkit in favour of a gecko backend!
For a more serious note, which one will be the first web-backend to be rendered fully in opengl, with resolution-independence and will sit at a solid 60+fps, and also support normal & specular-mapped rendered blogs with a highly detailed face at the bottom showing the stats of zrusin's vitals in the form of the amount of blood on his face? :) I'll pick that backend!
You do smack-downs in a stylish way Zack. However, having read Harri's 'FAQ' yesterday, with respect, I think it was necessary. It's akin to King Canute just wanting the tide to go back, and on a logical level, it was just plain idiocy.
For a start, even as a KDE user, KDE has existed for a long time because of a solid foundation and code reuse. Why on Earth does everyone think that KDE uses Qt in the first place? Code reuse. KDE gets a lot out of that architecture. If QtWebKit is there, ready and available then it makes sense for KDE to simply reuse it, as with every other set of Qt classes KDE uses. KDE can, and does, expand on Qt even further (always has done) so I don't really understand Harri's points. This, I found utterly daft:
QtWebKit is a port of the forked KHTML sources that aims at providing a ready-made HTML component to Trolltech customers.........It just is yet another platform port without any influence on the feature set and therefore useless for KDE’s purposes.
Yer, just like most of Qt is irrelevant to KDE.
Secondly, as you say, if you are creating a HTML web rendering engine then you cannot live as an island. Web developers develop for the most well known and well used browsers and engines around, and engines-wise this consists of IE, Gecko (Firefox) and WebKit (Apple/Safari). That's it. As much as I like KDE, I'm not going to spend a ton of time finding out why something just doesn't work with KHTML in some bizarre set of circumstances (working out what some HTML and especially JavaScript engines do can be damn perplexing). This is the reason why stuff like GMail doesn't work properly with KHTML, and it almost certainly never will. This is never going to be good for KDE or anyone.
Combining these two points, it makes sense to pool as many resources as possible, get together, share and create as big a target as possible for KDE and web developers. It makes life easier for Qt and Trolltech, makes life far easier for KDE and has additional, indirect and much, much needed benefits for KDE's (and Qt's) users and web developers. Hopefully, we won't have to faff about telling people to change their user agent strings to get a site to work, or trying to get the tide to go back by telling web developers to support KHTML when the effort makes no logical sense.
Qt must make use of WebKit, and in turn, KDE needs to make use of QtWebKit in the way that it always has done with Qt. It just makes sense from every angle and is the only logical choice. Who does the work decides, and it certainly seems to be what most developers want and it is certainly what KDE's users want and need.
Just some general responses:
- there is a QtWebKit KHTML part. Maintained by Simon right now. Furthermore much of QtWebKit design has been tailored towards KDE. So yea, whoever pointed out the lack of KDE in WebKit doesn't know what he/she is talking about.
- About Lars, Simon or Trolltech people not working on KDE - that is the most bogus argument in the history of bogus arguments. Those people work on a library that the whole KDE is based on. Every single line of code that you (assuming you write code at all) or any other KDE developer writes is thanks to them. Furthermore they (surely me) and many others moved to Norway at some point, exactly for that reason - to make sure the KDE foundation is there. And for people to have the nerve to actually draw the line between "I'm a KDE developer because I contributed a line to a project Z in KDE SVN" and "He wrote and maintains thousand of lines of code on which KDE is based on, so he's not a KDE developer" is just outright delusional.
- About me not maintaining KDE code - I have been maintaining and keeping kspell working for what six years now? And Sonnet is nowhere even near dead, in fact I think I got it in a good shape for 4.0 and we have more plans for it. You last commit story is also not true. Check the logs. Given that you posted as anonymous it's hard to tell but if you can show me how you maintained a piece of software over a span of at least 6 years, we can continue this discussion.
- robert: i know it's totally "in" right now to be insulting the work that Trolltech is doing ("irrelevant QtWebKit") but since I don't work for Trolltech anymore and no one can write me off as "biased" I'm going to hit back people who do so.
So ... how does that fit in with the fact that you haven't actually made a commit to KDE's SVN repository since March 2005
There's an awful lot outside of KDE, that KDE depends on and needs, that people have contributed a huge amount to.
As he mentioned, a lot of KDE people make contributions to WebKit and QtWebKit away from KDE and KHTML. The KDE work will probably be done in the same way as a lot of other things in KDE 4 - release by release. Ignoring that work and going your own way just seems rather daft.
momesana: yours is a very good start point for a new Web browser based in QtWebKit for KDE.
Honestly I belive that in the end, we will have different programs for browsing and for file managements. I strongly recommend you to free up the code in kde subversion so that other developers can join your project. I promise I will try to collaborate in my free time, which is not much but probably enough =)
Well, in my eyes Harry is pretty right. WebKit is no option for KDE 4.0 since 1) QtWebKit as well as Qt 4.4 are not ready yet and 2) we are in feature-freez anyway. So, Harry is imho pretty right that QtWebKit is without any influence for KDE 4.0 and depending on open decisions re API-compatibility maybe even for the whole KDE4-lifetime, right?
p.s. everything beyond KDE 4.0 is a moving target anyway and guess we just have to wait and see what happens.
I keep my fingers crossed for you Zack. WebKit must replace KHTML in KDE 4 (I hope it will happen at least in KDE 4.1). Ego of some remaining KHTML developers should go aside. Go, QtWebKit, go!
ups, s/Harry/Harri/ ... I am sorry for that stupid typo :-/
Zack: By releasing Sonnet in time for KDE 4.0 in a wokring state so that it works in $BROWSER and Kopete input fields just like KSpell2 does in KDE 3.x you would do me the greatest favour ever!
@edulix, @patpi
Don't worry. I'm spending a lot of time tinkering with the code and I will release it at some point. As of now, its really way to ugly to be released and I miss alot of features from FF and to some lesser extent konqueror. Furthermore, the QWebKit stuff needs to improve before the browser becomes usable.
p.s. Someone pleaaaaaaaaaaase implement the registerForIconNotification method in FrameLoaderQtClient.cpp so that favicons work again. :'(
Sebastian Sauer: In my eyes, Harri isn't right, he has only injured ego.
Btw. on KDE 4.0 API Reference KHTML page is written:
"KHTML is likely to be superseded by WebKit in KDE 4.1 / Qt 4.4."
So there is really chance that KHTML will be replaced by QtWebKit in KDE 4.1 (despite injured ego of remaining KHTML developers).
Zack, as per usual on your posts I was laughing out loud whilst reading it. While the smackdown was fairly non-subtle, I think it was deserved and agree with almost all your points.
I for one am very upset by the fact I'm using Firefox as my browser in KDE now because Konqueror just doesn't work well enough across enough of the web now.
The day that KHTML has better support from the web development community is the day I think it is a superior solution to be using. Until then WebKit is better for both the users and the web developers and seemingly the only ones who suffer are those who have some emotional attachment to KHTML.
Emotional attachment is _everything_ in this quarrel. But as Aaron just pointed out, the market decides. Devs are by nature passionate, but the cold market doesn't care.
> Especially the part that mentioned QtWebKit as an irrelevant fork of KHTML sources.
I read it carefully. It didn't. Please stop sounding like Balmer with a piece of chair in his mouth.
This is an interesting debate, but I agree that the whole "we should switch to WebKit for site compatibility" argument is a poor one to justify dropping KHTML for WebKit.
As others have mentioned, if site compatibility is *really* the reason then shouldn't there be more effort given to a Qt port of Gecko rather than WebKit?
It's good that Apple put WebKit on the map, but Gecko was already there and still has more marketshare. I'm sure the same web developers who "don't" want to test against KHTML in addition to Trident, Gecko, Presto & WebKit would love to drop a couple more marginal rendering engines from their testing process.
anonymousx: Now read it with understanding. (judging by what you wrote it will hurt)
anonymousy: you're missing the point, it's about picking the better technology. WebKit is the better technology, which is why we dropped QtMozilla in favor of QtWebKit. The compatibility with Safari in itself is worth more than any patches that are in KHTML right now though.
Furthermore the point that everyone seems to miss. I'm not saying that people need to drop KHTML. They can work on it until the end of time. What I don't want them to do is present their ideas as if they were representative of KDE. They're not. Those are opinions of the individual engineers. And ultimately, as Aaron pointed out, it doesn't matter people will use what is better.
Do the math: three years ago 3 by far, far best web rendering engineers we ever had, Lars, Dirk and Antti agreed that we can't keep up with the work Apple is doing. Dirk, Lars and I sat down to do QtMozilla to give KDE a decent web rendering engine.
So
KDE work on KHTML < Apple's work on WebKit
Three years later suddenly:
"KDE - 3 best web rendering engineers we ever had" work on KHTML > Apple/Trolltech/Gnome/KDE work on WebKit.
What? How does that exactly work?
Not even mentioning that 2 of those 3 engineers (Lars and Antti) now work on WebKit...
"Web works on the principle of percentages - web-designers test their sites with engines that have X% of market reach. Konqueror with stock KHTML isn't even on their radar. WebKit is. Having web designers cater towards their engine is worth more than gold to KDE users."
While a lot of what you say is sensible, the above? Is not. If market share is all that matters, why not just use Gecko? Or, even better, imitate IE? One can't just say "Marketshare is King!" and then proceed to imitate an also-ran when other browsers are far, far, FAR more popular. Its a contradiction in basic assumptions.
No, the effort should NOT go to making something "bug-for-bug compatible" with something else, no matter HOW much market share it has. The effort should go into a) standards compliance and b) getting web developers to write for a.
Read what I wrote above.
KHTML and WebKit should merge, there is no point in having both around doing the same thing.
anonymous: KHTML did merge, but WebKit was the receiving project.
WebKit has a few advantages of the original KHTML, including better Javascript support and an abstraction layer that makes it easier to port to various operating systems and architectures.
It will be interesting to see, once KDE officially uses WebKit, whether the developers still working on KHTML shift their efforts to WebKit or blinker themselves to direction things are going.
Post a Comment