Safari And KHTML May Never Meet

diegocgteleline.es writes "Announcing that Safari passes the Acid2 test has raised some voices in the KDE world. 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. It's quite likely that KHTML developers will have to write their own code to pass the acid2 test. Zack Rusin writes: '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.'"

Comments

He posted patches!

[Knytefall]

Looking at Safari developer Dave Hyatt's blog it looks like he's provided some patches. I'm sure it will take some work to get those into KHTML, but that seems to be a pretty good start to me.

Re:He posted patches!

[masklinn]

From Rusin's post, these patches are not useable (mainly because they often rely on previous Safari specific implementations that don't exist in KHTML trunk, or for the worse ones because they rely on OSX features itself and thus can't be ported to KHTML without a full rewrite)

As if that ain't enough...

[Sirch]

... they're duping comments.

Hey, that gives me an idea - find a nice little comment somewhere a week or so back and submit it as news... yeah...

Has anyone asked Hyatt?

[byolinux]

Dave Hyatt seems fairly responsive to emails. He's replied to one's I've sent in the past asking questions about Safari. He's a Free Software guy, I'm sure he can appreciate the frustrations here, and might be able to help - afterall, I don't believe he, or Apple really want to 'screw over' the KHTML people - it might just be that communications haven't been really made.

Email him - ask?

Re:Has anyone asked Hyatt?

[booch]

You don't need to ask him. He's blogged the whole thing! He's got a separate patch for each change in functionality, with explanations of each. Some "explanations" are just a single sentence as a link to the patch. Others are full blog entries. The blog provides a pretty good history of his thinking on the changes as he went along and tracked his progress. The patches are also commented to a reasonable degree explaining what's going on.

If this isn't enough info, I don't know what is. I suppose code for regression tests, etc. would be nice. But complaining about this is more likely to piss off Apple/Hyatt than to help. Plus, he does have his email address posted on his blog if you have questions. Or just post a comment, and I'd bet he'd answer it.

Re:Has anyone asked Hyatt?

[palndron]

I think they are saying the Hyatt's patches are the exception not the rule, that they have not been getting patches in managable chunks at all, and when they get them they are huge tar balls with no change logs.

Public release of Safari does not pass yet.

[MarkByers]

This might be a good time to remind everyone that the patch has not yet been released to the public. The patch might make the browser unstable - further testing will be required. Depending on how long it takes before the patch makes it into the public version, Safari might not be the first browser to support Acid 2.

From yesterday's summary:

The patched Safari is not yet avaliable for public consumption. It is unknown when the patches will appear in a public version of Safari.

Re:diff -uBwr KDE_KHTML/ Safari_KHTML/

[unixmaster]

When the diff is 6MB yes its damn hard.

Re:Stop complaining

[unixmaster]

Huh? They got Khtml and Kjs from KDE, without them there is no Safari , No Dashboard. Got it?

Why cvs history is important for Khtml etc.

[unixmaster]

Every change in khtml has to be run through a regression suite to make sure it doesn't break anything. Now if you fix something a new regression test is added for that.

If you get fixes with no log of what they fix you will end up with bunch of code which you have no idea how to test for regressions. This is just one of the reasons why diffing codebase doesn't cut it.

Another good reason is damned diff is ~6mb because Apple guys never send small patches but only dump WebCore tarballs.

Re:Is this a joke?

[Elwood P Dowd]

Conveniently, this time you didn't even have to RTFA. Right there in the abstract:

'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.'

Maybe I missed the part where he said that Apple had to hand-hold him through understanding the code. Oh, no, in the article he points out that Apple has fulfilled all the requirements of the license.

Re:Hmmm...

[k98sven]

Now that diff can't tell you why they've changed, but for Pete's sake, you're a developer. You've got the code. You've got the standard. You've got the changes in the code. You've got the old code. You can see how behaviour changes in each. You've (hopefully) got an reasonable general understanding of the codebase.

You obviously didn't read the blog entry.

The problem here is that Apple drops a huge diff on them for every release. It's not individual diffs for each change, but one massive one. We're talking about a diff several megabytes in size consisting of hundreds of changes. With all kinds of changes mixed in with eachother and mixed in with all kinds of Safari-specific stuff.

Yes it is possible to sit and pick that apart. But it's a lot of work. It may very well take more work to seperate out a change than to re-implement it from scratch.

On top of that it's unnecessary work, because there's no reason Apple wouldn't be able to hand over all individual patches seperately, which would make things immensely simpler for the KHTML guys.

Apparently the KTHML guys have tried and tried to get Apple to do this. And they haven't helped.

Blog Entry

[David Saxton]

I can't access kdedevelopers.org, so here's the blog entry:

You cant 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. Whats 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 its not going to be Allan or Germain its not going to happen).

Code in Safari is hugely inconsistent and changes are always interdependent. Theres basically no way of merging in one change without bringing a whole bunch of others in. And you know what? Dont even tell me about merging stuff like render_canvasimage.h,cpp. It outright uses OS X apis. Well never be able to merge that in - someone will have to implement it. And whats 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 its well finally! It was working in Safari. khtml developers are lazy. Wheres 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 doesnt have any history? Thats 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 NDAs 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? Thats their right. They made a conscious decision about not working with KDE developers. All Im asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. Theres absolutely nothing great about it. In fact it doesnt exist. Maybe for Apple - at the very least for their marketing people. Clear?

Re:Wow - vitriolic

[I confirm I'm not a]

it seems like they're doing everything they're legally bound to do. And that only, nothing more at all, which is the part that annoys the KHTML team.

Not even that: it's *other people's* attitude that the KHTML devs dislike - from TFA:

"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."

Re:This sounds like something SCO would say...

[Carewolf]

Actually the biggest problem right now is that Apple are not keeping up with code-cleanup. We constantly try to develop more elegant easier to maintain code, where as Apple wants the right features - right now.
Safari is basically still KHTML from KDE 3.1 with a ton of bug fixes and features. Many of the features takes time to port because they do not live up to our coding standards.

Re:diff -uBwr KDE_KHTML/ Safari_KHTML/

[imsabbel]

Only if you have OSX installed...
(see article, those patches actually require MacOs functions)

Re:Wow - vitriolic

[coolGuyZak]

They are just getting criticised because some developer wants them to do more.
Read this, as I don't feel like typing it again.

You are clueless... You haven't even bothered to read the article...? Typical Slashdot attitude.

Re:Why give back?

[slick_rick]

Did you even read the linked articles? He isn't complaining about Apple. He is complaining about jerks like you bashing KHTML on Slashdot for not incorporating Apples sloppy hacks back into KHTML.

Re:Isn't that what opensource is about ?

[zorander]

They're providing the modified source code. What they're not doing is adhering to the project management standards (version control, changelogs, whatever) that KHTML uses. The GPL doesn't require this. As I see it, Apple is modifying and using KHTML and releasing the modified source back to the KHTML team, thus fulfilling the GPL. There's no requirement that it be easy to build or that they document their changes well or that they not fork the project.

In fact, forking is not a bad way to describe what they're doing. They've made a legitimate fork. They're releasing patches, they're playing by the rules.

The OP is right. They're not 'cooperating'. Guess what--they don't have to. The GPL, however much RMS would like it to, doesn't mandate having a social conscience.

Missing their point

[ElMiguel]

Why is everybody missing this KHTML developer's point? It's right there in the short Slashdot summary. He acknowledges that Apple is fulfilling their legal obligations by providing the modified files. But they're not providing any help at all in making their changes useful to the KHTML team. So, there's no "collaboration" at all from Apple's side. That's all. He's not even flaming Apple. If anyone, he's flaming people who misunderstand this situation.

Re:This is natural

[browse]

Apple doesn't use CVS as their normal source control system.

Ummm, yeah, they do. I worked within Apple's OS division for several years of OS X development. Source control is all done via CVS.

Re:Business Plan

[FidelCatsro]

SO your basicaly saying Apple has a good business plan and make a quality product which they totaly admit partly comes from others work.

They don't take credit for the lot, last time i checked .
They only take credit for the inovations they add , apple have been quite open as to the fact that alot of darwin is based on free OS software ( i would say they publicised that to gain the OSS vote )

As for the rest well , Apple Dont want to reinvent the wheel and i dont see the problem with that .