APR
28
2005

So, when will KHTML merge all the WebCore changes?

Submitted by zack rusin

You can't even imagine how I hate that question. The truth is "most probably never". I just read the article on /. about Safari supporting the "all crack Acid2" test and people raving how great it is for KHTML. The truth is that KHTML will probably never get those patches. What's most probably going to happen is that one of us will simply reimplement it from scratch (and at the moment the reality is that if it's not going to be Allan or Germain it's not going to happen).

Code in Safari is hugely inconsistent and changes are always interdependent. There's basically no way of merging in one change without bringing a whole bunch of others in. And you know what? Don't even tell me about merging stuff like render_canvasimage.[h,cpp]. It outright uses OS X api's. We'll never be able to merge that in - someone will have to implement it. And what's going to happen when someone does? Some jackass on /. or some other equally stupid site will be praising Apple.

In the past when someone spent long hours implementing something in KHTML, they at least got a "thank you" from people using Konqueror. Now it's "well finally! It was working in Safari. khtml developers are lazy". Where's the fun in that?

Do you have any idea how hard it is to be merging between two totally different trees when one of them doesn't have any history? That's the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDA's with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL.

And you know what? That's their right. They made a conscious decision about not working with KDE developers. All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist. Maybe for Apple - at the very least for their marketing people. Clear?

Comments

Kudos to you and whole khtml team who made a god damn fine html rendering engine!

By ismail at Thu, 04/28/2005 - 19:35

I am still amazed that someone was so brave to go out and build a brand new mainstream html rendering engine from scratch, when projects like Mozilla and Opera were already well underway. Your effort has been tremendous and it's certainly under-appreciated, because the Big Players (Apple and Moz) always manage to steal the scene thanks to their commitment to Free software being minimal.

Don't mind the slashdot crowd, it's not worth it. KHTML's glory is elsewhere; every time I see and use the amaroK left bar, for example, I think it's so cool that puts any Gnome enormous and unflexible widget to shame.

By Giacomo Lacava at Fri, 04/29/2005 - 12:21

This is really sad. I have only seen small patches from time to time in the cvs-digests, so it does not really surprise me. Hell this is not the way lgpl should be used. I mean they got (and probably are still getting) stuff from khtml and refuse to pay anything back. I mean there are still significant changes made, the adblock filter for example, so why don't we (I mean you:) just change the license.
Stop apple!

naked&dead

By miro at Thu, 04/28/2005 - 19:39

Because this is exactly what the LGPL is for. If you don't believe me, go read it again.

The LGPL is not some magical formula for merging two forks -- it's something that allows for evolution (for better or worse) of a code base.

It's nice when people cooperate, but in fact the right to fork is one of the more important points of the (L)GPL.

I don't mean that it wouldn't be great if the Apple folks actively worked to get their stuff in a state that it could be merged back into KHTML, but there's no reason to enforce that from a licensing perspective (which is impractical anyway because of the number of copyright holders).

By Scott Wheeler at Fri, 04/29/2005 - 10:33

As a KDE user who hopes can one day code for a living, I understand it must be very frustrating sometimes. So I just made an account with the sole purpose to say I love Konqueror, and many many thanks to all people who made KDE and this amazing stuff possible. This world would be a much better place if people were just grateful for they have instead of whining for what they do not. So, maybe "thanks" it's not much, but hey, it's how I feel.

By episode96 at Thu, 04/28/2005 - 22:07

Here's from another long time KDE user who is saddened by the KHTML/Apple issue (to some degree because of how it's being reported). I deeply appreciate the fine work of the KDE team and want to say thank you.

By john_evans at Fri, 05/13/2005 - 18:58

Hi,
I know 'bout your feelings. Well, so here is my words to you:
Big thx and applause to all your efforts...
... there is at least thousands of people out there benefitting from your stuff in everydays work.
I am sure they'd thank you if they knew about that.

pls be patient with the green fruit, I still hope they somehow give something back on either way

By forgetfast at Fri, 04/29/2005 - 00:27

1. KHTML was dead before Apple decided to adopt the project for Safari, don't forget that. The usual way had been a move to the gecko engine, this was already in preparation. There would be no KHTML today without Apple's committment.

2. Well, Linux users do not use Safari, therefore it is irrelevant what runs on Macs.

3. You say Apple uses native API. You can also think about implementing the Apple API, so that the code runs on Linux as well. Soemthing in between of Softpear and GNUSTEP. Everybody likes the APPLE engine, why not rebuild it. It's documented.

4. You shall communicate this loader, Apple is marketing sensitive.

By elektro at Fri, 04/29/2005 - 04:12

A modern GUI API is nothing without HTML rendering capabilities. KHTML is more then just Konqueror.

By [email protected] at Fri, 04/29/2005 - 08:10

> KHTML was dead before Apple decided to adopt the project for Safari, don’t forget that.

Do you have any prove for this bold claim?

> There would be no KHTML today without Apple’s committment.

You contradict yourself here. As you have just learned, not many Apple patches were merged back into KHTML. So how did Apple's committment helped to keep KHTML alive when only a small amount of their work was reused in KHTML?

By Christian Loose at Fri, 04/29/2005 - 08:43

Pages