APR
28
2005

So, when will KHTML merge all the WebCore changes?

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

Before Apple decided in favour of khtml as a basis for Safari khtml was a project which was about to be abandoned in favour of Gecko. A gecko-replacement for Konqueror was in the pipeline. Nobody thought khtml would survive as the html engine for KDE. After Apples Safari decision nobody questioned anymore khtml, nobody called it a wasted effort.

The Apple committment gave a spiritual push to the project, regardless what they contributed or not and today we watch the fruits of the wonderful khtml development done by KDE developers.

So Apple gave back confidence in the project. Rhis was not their merit, it is just a fact. And today we know it was a good decision to continue khtml development because both khtml and gecko are very fine.


By elektro at Sat, 04/30/2005 - 01:20

"Before Apple decided in favour of khtml as a basis for Safari khtml was a project which was about to be abandoned in favour of Gecko.". Alright, this is it. I'm done here. I'm not reading comments section of any news site anymore, now I'm stopping reading comments to my blog. This is so unbelievably wrong, I'm just speechless.


By zack rusin at Sat, 04/30/2005 - 02:43

If KHTML is dead then I am the Queen of England :)

Look at the CVS of KHTML and you will see that it is alive. KHTML now support CSS shadow in better way that Webcore does, it support CSS numerotation too (the only browser with Opera).

Without Apple's committment, KHTML would be what it is today. The time spend to merge the few Apple patchs that can be merged would have been used for implementing other things or this things. So nothing new under the sunshine. With or without Apple things are the same.

Apple had made a KHTML fork. They don't collaborate on KHTML. The worst is that they keep the name "khtml" for proprietary CSS name (-khtml-*) and for the user-agent so now people only test websites int Safari pretending that it use KHTM engine. No ! Safari use Webcore and Webcore is not KHTML ! Webcore and KHTML differ in their implementations of CSS/(X)HTML. Webcore is sometimes better and sometimes worst than KHTML.


By Franck at Fri, 04/29/2005 - 10:12

Khtml was about to be abandoned back then.

I do agree with almost all what you say, I do not see a contradiction.

I think that even if Apple did not provide a single patch, just their commitment for khtml gave a strong push to the project.

I do not praise Apple for that.

Without Apple I guess pressure to give up khtml would have become apparent, duplicated effort ... and so on. KDE already had a gecko interface in the making, I don't know the current status. Wasn't there also a crappy Gnome html engine? What happened to it?

But it was right to continue the project and I am very glad to look at what happened. Further khtml is just great and I do praise the developers for it. We always had problems with Konqueror 2-3 years ao but now the engine is mature. I hardly get any problems. Khtml is ready for me today.


By elektro at Sat, 04/30/2005 - 01:28

Reading things like this is so sad. "Khtml was about to be abandoned back then."? No, it never was. Why would ever think that is beyond me. "KDE already had a gecko interface in the making". No, we never had a working Gecko engine on KDE libs and we never worked on it. One guy from Corel was working on it and it had very little to do with KDE in the first place. Please have mercy on what's left of my nerves.


By zack rusin at Sat, 04/30/2005 - 02:34

I'd just like to say that your work on KHTML is very much appreciated.
The amount and quality of work that went into the engine is simply amazing.
Don't let a single troll on your blog ruin your day.


By KDE User at Sat, 04/30/2005 - 04:54

I also registered just so I could tell you how much I appreciate what you do.

KDE is my favorite Linux GUI and always has been. There was a time when I wondered where Konqueror was going, but it truly has come a long way.

If Apple wants to be this way, and hold back or not be supportive, so be it. Personally, I think we all knew that would happen because of how they have handled themselves in the past. It was no big surprise. I think we were all hopeful that they would be better stewards, but as noted, it is allowed for in the (L)GPL. It may not be the nicest way to handle things, but it is something they can do. I guess, their idea of what a community is and is not, is just very different.

The KDE Team has done great things, and will continue to do so, because of their great commitment to a community who has truly appreciated what they do and because of their commitment to the project itself. From what I can see, the KDE Team takes great pleasure and pride in the work they do. But no one can work forever without positive feedback....so...

Thanks again and keep up the great work! It is very much appreciated!

LilBambi


By lilbambi at Fri, 04/29/2005 - 16:45

I can understand your frustration about Apples behaviour. It's legal - but not fair.

On the other side: should Apple not use its own libraries and APIs? Should Apple test against KDE to ensure compability?

Did somebody expect that?

For Apple it would be wasted time to do so.

Because Apples resources on their KHTML branch seems to be bigger, let them make the work of implementing new features. And make a KDE-Webcore layer to make their work running on KDE.

I know, that IS a hard decision for those who invented the thing. But on the other side - why not rip-off Apple? Their KHTML branch is the de-facto standard in terms of installed user base, web conformance and speed. As a programmer I know that is not exactly the kind of "fun" as moving your own KHTML branch foreward. But its pragmatic at least.


By mine at Fri, 04/29/2005 - 16:56

From /., a very well thought out reply to the blogger's rant:

Apple, they say, isn't playing friendly. They don't provide a CVS history, just the modified files where nobody can understand how and when things have changed.

First of all, anytime you fork off a large project like KHTML the source code bases will start to grow apart. When the new fork has a dedicated group of engineers updating it for their needs then it will quickly diverge to the point where it makes little sense to attempt to keep patches in lock step. In my career I can recall several times where this has happened, and it always seems to come as a surprise to the people maintaining the less active fork.

Apple doesn't use CVS as their normal source control system. To provide CVS documentation, Apple engineers would have to maintain a CVS database as well as maintain their patches in their standard internal SCS. This used to be perforce, I believe, and probably still is as switch a SCS is generally a royal PITA.

Because the sources have been diverging for several years, it's unrealistic to expect that the Safari patches will be directly applicable to KHTML, and I frankly doubt that even having the Safari patch documentation would help very much after several years of Apple patches. This probably isn't anything underhanded on Apple's part. It's just the way engineers work - they change the code to fit their needs, and rarely consider the impact on the old fork that they started from in the absence of an explicit mandate to stay compatible with the old fork. That level of compatibility would require the Apple folks to always have the current KHTML sources and be familiar with that source and particularly to understand the differences between the KHTML code and the Safari code.

Apple does provide the modified files, and usually this is a huge improvement on starting from scratch in implementing a new feature or fixing bugs. It does require the KHTML engineers to be able to read and understand the Safari code. To say that nobody can do that sounds a little strange.

It's quite likely that KHTML developers will have to write their own code to pass the acid2 test.

Well, yes. Should Apple engineers be expected to maintain the KHTML engine also? Apple's engineers are probably focused on their code base exclusively. The KHTML engineers are the right people to modify their own code base. Does anyone expect Apple engineers to be responsible for maintaining compatibility between Safari and KHTML? Apple makes changes, and they provide the changes files to the KHTML team. The rest is up to the KHTML folks if they want to extract the Apple code they want to use and put it into their code.


By thorshammer123 at Thu, 05/05/2005 - 20:51

"On the other side: should Apple not use its own libraries and APIs? Should Apple test against KDE to ensure compability? "

No, but they should not be putting Cocoa/Object C code in patches to KHTML. Writing an abstraction layer wouldn't be that hard and would be beneficial to everyone (including Apple) in the end.

Apple doesn't have to play nice, indeed it certainly does not benefit Apple from improving potential competition. Mr. Russin only wants people to know that Apple is contributing very little back to the KHTML community and shouldn't be given kudos for "saving" or "improving" KHTML. This sounds perfectly reasonable to me.

Apple is a company and no matter what Apple (or their users) claim about helping the "community", they rightly care for only one thing... the bottom line.


By am at Fri, 05/06/2005 - 08:14

Pages