The Unforking of KDE's KHTML and Webkit Begins

Jiilik Oiolosse writes to tell us Ars Technica is reporting that after years of existing seperately, KHTML and Webkit are finally coming back together. "In open source terms, this may be as big of a deal as the gcc and egcs merger of yonder days. KHTML and Webkit are definitely coming of age. The KDE developers, responsible for the original creation of KHTML, are dedicated to seeing this unforking happen and are taking a leading role in that effort."

Comments

Unforking?

[Anonymous Coward]

I believe you mean KHTML and WebKit will be *spooning* soon!

Re:Unforking?

[jd]

Spork.

Webkit wins

[dj_tla]

The summary is a bit vague as to what 'coming together' means. Basically, Webkit is going to be adopted in KDE as a Kpart, features in KHTML that aren't in Webkit are being added to Webkit, then KHTML will die out. Seems at least some KHTML developers will be working on Webkit in the future. The article also goes into the history behind the forking, and is actually a decent read.

Re:Webkit wins

[stilborne]

i think a more accurate term is "everybody wins". the code bases have evolved and it has come time to bring the best of all worlds together. the path chosen to get there is interesting, but not a matter of winners and losers.

Re:Webkit wins

[stilborne]

> what 'coming together' means

i suppose i could be a bit more helpful and comment on this as well..

> Webkit is going to be adopted in KDE as a Kpart,

what's happened is that the Qt rendering layer has been added to the main webkit repository and several people at Trolltech and from the KDE community are working on webkit and the Qt based rendering in that repository.

this opens the way for webkit to show up in kde, including the kpart.

hopefully more of the khtml forks will follow suit and join mainline dev, but this certainly does start to bring together two of the bigger and more knowledgeable teams when it comes to khtml/webkit.

> features in KHTML that
> aren't in Webkit are being added to Webkit

as many as possible, yes.

Re:Webkit wins

[shutdown -p now]

I wonder if this actually means that WebKit will become a standard Qt (and not just KDE) component. Qt has its own HTML rendering engine currently, but it's rather simplistic. I wonder if Trolltech has decided it's time for something more powerful...

Re:How is it?

[ZachPruckowski]

Well, it's a famous forking/unforking story regarding GCC, and today we've had a GCC forking story, and a forking->unforking story. Since stories about successful unforks and stories about GCC aren't all that common on Slashdot, it makes sense you haven't seen it here before.

Fortunately, in this case the reference is actually relevant to the process and the discussion. In the GCC story, it was completely unrelated to a license-based fork of GCC.

Re:Impact on Apple

[ip_fired]

When I worked on WebKit, the source that was publicly available was the source that went into Safari after it's had been adequately tested. They don't have a super-secret version that they are adding their improvements to. The version they improve is the LGPL version.

In fact, you can go and download the nightly build of WebKit and use it with Safari (Safari is just a wrapper that provides the gui).

http://nightly.webkit.org/

Re:Impact on Apple

[Otter]

One of the problems is Apple has no interest in keeping a GPL'd webkit fully functioning with tidy entry/exits for whatever proprietary things Apple wants to add.

Huh? How do you get that from a story about Apple providing such an attractive fork that everyone, including the original authors, is switching to it?

The piece you quoted refers to a squabble about changes to Webkit being difficult to port to KHTML. Which, as the article notes, has been long resolved to everyone's satisfaction.