Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Unforking of KDE's KHTML and Webkit Begins

Posted by ryuzaki0 on from the sounds-dirty dept.

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

10 of 104 comments (clear)

  1. Re:Impact on Apple by Jiilik+Oiolosse · · Score: 3, Informative

    KHTML/Webkit and derivatives are under the LGPLv2, and the rights were not assigned to a central organization. They would have to contact every author that ever touched that code before they'd be permitted to offer it solely under the LGPLv3...

  2. Re:How is it? by jshriverWVU · · Score: 2, Informative

    egcs was a fork of the gcc tree, and had some nice pentium optimization back in the day. See link.

  3. Webkit wins by dj_tla · · Score: 5, Informative

    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.

    1. Re:Webkit wins by stilborne · · Score: 5, Informative

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

  4. Re:Impact on Apple by ip_fired · · Score: 5, Informative

    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/

    --
    Don't count your messages before they ACK.
  5. Developers abandon KHTML for the WebKit fork by homesnatch · · Score: 2, Informative

    This is a more accurate subject line. If you read the article, it is clear that the original developers are moving to WebKit instead of KHTML.

    From TFA:

    While there are still a few reservations, the consensus is to develop a Webkit KPart for embedding into Konqueror at the earliest opportunity and to take a more active role in the development of Webkit itself. This was hinted at earlier in an Ars interview with Lars Knoll, but now it is more or less the official word.

    Now, KHTML won't be deleted right away since there are features in it that need to be ported into Webkit. For example, KHTML (in KDE 4) implements portions of the definition of the CSS3 standard, which will need to be adopted into Webkit and so forth. But the big deal is that the coders that invented the underlying layers that power Konqueror, some Nokia browsers, Abrowse, Safari, Adobe's Air, and now Epiphany and a few other projects that are in the works, are now back in the fold.

  6. Re:Can you get Windows Binaries? by ip_fired · · Score: 3, Informative

    I believe the nightlies are actually compiled DLL's (or shared libraries, depending on which OS you are on). You can point the safari executable to use the nightly builds instead of the shipped build.

    With that said, the nightlies can be buggy, leak, crash, etc. After all, it's just what the devs checked in the previous day and it hasn't really been fully tested.

    I was just trying to make the point that the guts of Safari is open source, and that is where Apple puts it, it doesn't have a separate branch that it works on.

    --
    Don't count your messages before they ACK.
  7. Re:How is it? by 1729 · · Score: 3, Informative

    The real beauty of EGCS history is when RedHat 6.0 shipped with a snapshot version of EGCS instead of tried and true GCC 2.98, and called it GCC 3.0. Of course, since it was just a daily snapshot and not even a release candidate, it was buggy as all hell. Couldn't even compile a kernel because some of the inline assembly and undocumented behavior changed. What a huge piece of shit, thanks RedHat.

    It got so bad, FSF had to disavow all knowledge of any GCC 3.0 compiler and jump to 3.1 immediately, since invariably GCC was blamed for this debacle, instead of the true idiots: RedHat.

    The more you know.


    Your facts are a bit off:

    http://www.gnu.org/software/gcc/gcc-2.96.html

    In particular, note that the gcc-2.96 debacle had nothing to do with egcs. GCC 2.95 was released after the gcc/egcs merger and before Red Hat released gcc-2.96.
  8. Re:thats the end of the world as we know it by stilborne · · Score: 1, Informative

    add Adobe with Air to that picture, and there are Others(tm) lurking with webkit trees.

  9. Re:thats the end of the world as we know it by Anonymous Coward · · Score: 0, Informative

    + Adobe, which uses WebKit as its HTML renderer in Adobe AIR.