
This past Summer, the news broke that the KDE project has plans to re-merge KHTML and Webkit. It appears the KHTML team is not going gently into that good night. (Updated 12:23 on Fri 26-Oct-07)
Back in the day, Apple worked with KDE's KHTML team to some extent, apparently being none too friendly in their contributions back to the project. Eventually, Apple released WebKit under libre terms, and some prominent KDE developers have been planning to use qtWebkit as Konqueror's new rendering engine since most websites get tested for Webkit, along with Gecko. To be clear, Webkit was essentially a fork of KHTML, and the KDE devs want to merge it back. As is typical of most FOSS projects, the discussion is not an open-and-shut case.
Ars Technica the "possibility that KDE will switch to the Webkit engine in its desktop software as opposed to a pure KHTML solution." A month later, Troy Unrau went on to say, "This was hinted at earlier in an Ars interview with Lars Knoll, but now it is more or less the official word."
Unrau's announcement on Dot KDE set off a rather heated discussion that drew Aaron Seigo's attention and admonishment. KHTML's Harri Porten recently posted the KHTML Future FAQ, stating, "Despite rampant rumors floating around there are no such concrete plans." Ah, but the plot thickens! Zach Rusin blasted Porten's FAQ as fiction.
Several people challenged KHTML founder, Lars Knoll, and others, suggesting they are in no position to determine which rendering engine Konqueror should use, since these developers seem to be less involved with KDE these days. On the other hand, Rusin pointed out that Knoll, himself and others continue to contribute quite heavily to QT and KDE. Knoll continues to develop the libraries that enable KDE developers to work on KDE. People also questioned whether choosing Webkit would leave development in the hands of non-KDE 'management', but Webkit's license, combined with other factors make that much less risky - Webkit can always be re-forked, if necessary.
So, what's the situation? Well, it appears that KHTML will remain the web rendering engine for Konqueror going into KDE 4.0, and that it could be changed to qtWebkit as of KDE 4.1. That does not seem to be officially settled, so much as the most likely scenario. It appears that the KHTML team seems hesitant about the proposition, while many KDE developers and users alike have expressed a very receptive attitude toward seeing Konqueror user qtWebkit. And Rusin made clear to a reader that he believes the KHTML team should continue their work as long as they like.
The challenge is that Webkit, which comes from Apple, is widely tested, and is thus known to work well with a large number of websites. KHTML is not as widely tested, and, for example, GMail doesn't work well with Konqueror. Many Konqueror fans have expressed regret at having to keep Firefox around just for sites like GMail, that don't recognize KHTML. Using Webkit would solve these problems, enabling many users to stick to one browser.
There were also suggestions that a separate, Webkit-based browser project be initiated, and one developer even has a basic, almost usable browser based on Webkit. Some have suggested that Konqueror will eventually need to be dis-integrated into separate tools. Frankly, I would hate to see Konqueror loose its Swiss Army Knife-like feature set. I have written on at least one occasion how I use it to transfer digital camera images straight to my personal photo gallery site.
That's the thing for me. Konqueror is so useful that, with only a few exceptions, it could easily become my one tool for file and web browsing tasks. It surpasses Microsoft's Internet Explorer by a long shot - and without being "integrated into the underlying OS". Throw in qtWebkit, give me greater control over tabbed browsing, and the Konqueror team could count themselves a loyal customer.
In my view, the arguments against a move to Webkit are not all that compelling. The best is that KHTML plays a role in other KDE applications - will they have to be re-tooled? And, just how easy would that be? What are the alternatives? Most of the responses I've seen seem to favor the switch to Webkit. But the switch needs to be done in a sensible fashion. I have faith the KDE community will ensure that happens.
Update: Allen Jensen offers his take on the debate. He offers a few more technical details that I haven't seen crop up elsewhere in the debate.
Comments
Semantic
So much work lies ahead, so little time to get this up and running. We are on the brink of a paradigm shift in the way the Internet is used. A shift from front end to back end. Where does this leave WebKit or KHTML? What can either offer the new "intelligent web"? We are working on RDF, OWL, SWRL, SPARQL for the next generation, some like to call it Web 3.0. O.K. If that makes you happy :)
My point is we should be focusing on the Semantic application platforms, and statement-based data stores, rendering these will be a challenge in themselves. I like Konquerer, it seems to have the capability to lend itself to the next gen - providing we are sure what that truly is. We don't just yet, but will very soon. I think we need a highly proactive approach, and the history of both of these does not bring that term to mind.
My 2 cents - Eileen
For QtWebkit
I'm for QtWebkit. It would be nice to finally be able to get rid of Firefox and just use a KDE app instead. We also have the option to for if necessary. I think having this included in KDE4 would really add to the experience!
Zubin