Disclaimer: I have no desire to re-ignite KHTML vs WebKit arguments. Rather, the purpose of this blog post is to hopefully enlighten a technical question.

Over the last few months I've heard many KDE developers in various forums bemoan the lack of a working and stable WebKit KPart. The motivation behind this complaint seems to be that KDE folk want a WebKit browser option for KDE. Thus the naive solution is to just get the WebKit KDE KPart in shape. Given this motivation... the solution is wrong IMO.

I can speak from some experience here. I've been working on QtWebKit for quite awhile and have also worked - in the past - on the WebKit KPart plus Konqueror integration that Simon started. For a time, it was building and running just fine. You could install it and change a configuration file and Konqueror would render using QtWebKit. However, the integration was *far* from complete. Plumbing the sources of Konqueror I learned a nasty secret: Konqueror is highly KHTML API specific. Konqueror has deep integration with KHTML that goes far above and beyond the KPart API. Creating a QtWebKit KPart is woefully insufficient for the purpose of providing anything more than a basic HTML viewer.

A simple HTML viewer is no where close to a fully modern desktop browser.

This all makes sense if you stop to think about the history of Konqueror. Konqueror is a generic desktop shell. It is designed to allow basic viewing of various documents in various formats. Of course, it has become much, much, more than that. And the key to this growth of features is Konqueror's steady adoption of API's above and beyond the generic KPart API.

Which brings me to my point: if parts of the KDE community truly want a modern browser based on QtWebKit they'd best be looking at solutions beyond Konqueror. Otherwise you are left with two hacky solutions: make a QtWebKit KPart that is API compatible with KHTMLPart OR migrate Konqueror source to make it less dependent on KHTMLPart. The former is not going to be fun as the KHTMLPart API is not refined or polished and highly KHTML specific. The latter can only be accomplished with a lot of work set aside for refactoring or through nasty '#ifdef KHTML callThisWay() #else callThatWay();'

Both of these solutions are sub-optimal in my opinion.

If you use QWebView, do you know how make its background to be translucent? Apparently, the trick is not so well known, hence I decide to share it here.

Basically it boils down the following code snippet:

QPalette palette = view->palette();
palette.setBrush(QPalette::Base, Qt::transparent);
view->page()->setPalette(palette);
view->setAttribute(Qt::WA_OpaquePaintEvent, false);

The first three lines set a new transparent brush for the page. This is necessary so that all the painting is blended properly. The last one ensures that the web view is not opaque, i.e. it does not paint all the pixels contained in its rectangle. Opaque paint event for QWebView is the default, most of the time you want to have a web page with typical normal background color, either set by the web page or something you specify as the fallback color.

If you combine QWebView see-through background with top-level widget opacity feature (see what Samuel wrote about this some time ago), you will get something like the following screenshot (the wallpaper image is Soft Green, from Valient Gough). Neat, isn’t it? Note that of course it requires a window system which supports composition, e.g. modern X11 window manager, recent versions of Windows, and so on.

As usual, the code for this short example is available from the git repository, just check the transparentweb subdirectory. Again, I already prepared both the Qt/C++ and Python (via PyQt) versions. Enjoy!

In the recent pre-release of Qt for S60 we have included a build of WebKit that compiles and runs on S60. This pre-release is an important milestone for this porting effort that started about half a year ago. Hence, I would like to briefly highlight a few things about it:

The main work is finding good solutions for quirks in the toolchain. That includes the ARM RVCT compiler and the Metrowerks compiler used by the emulator on Windows, both with their own unique set of challenges.

The team working on this consists of Norbert Leser and Laszlo Gombos from the Nokia Browser Team in Boston as well as Janne Koskinen from Digia and Kristian Amlie from the QtSoftware Team here in Oslo. In addition Ariya wrote the little but super-cool anomaly demo browser, which is included in the Qt/S60 Tower release. The port is still in early stages, but it’s looking quite good already and rather performant.

We’ve been maintaining the patches in separate repositories and we’ve been pushing patches in small steps upstream for a few months now. There’s still a lot to go, but things are progressing. And the result is looking really cool

Alessandro Portale has announced the “Tower” release of the Qt for S60. He writes that “there are three fresh modules: Phonon, QtSql and QtWebkit”, and adds that “QtWebkit on S60 is still considered experimental. However, You should already be able to start developing QtWebKit refined applications for the pocket.”

QtWebKit is a port of the WebKit browser engine to the Qt cross-platform application-development framework, and Qt for S60 is in turn a port of Qt to the Symbian OS, widely used on mobile devices.

A recent WebKit bug comment from Gavin Barraclough gives some insights into the rationale for the layered architecture and MacroAssembler used in the current JavaScript engine in WebKit. Some excerpts from that comment:

The abstract code generation layer (MacroAssembler interface down) is layered like a traditional compiler. In a traditional compiler, it is common to have an assembler layer completely independent of the compiler (often a separate application). The compiler takes a source code file, compiles it, and produces an output file of assembly code.…

Layering the compiler on top of an assembler in this fashion provides a number of benefits. For the compiler developer, layering the compiler on the assembler separates the instruction selection from the minutiae of machine instruction encoding. For clients of the compiler providing a well defined language for machine instruction generation is useful if the compiler provides facilities to bypass the higher level language, and directly emit a specific sequence of machine instructions…

The assembler interface within the JIT is designed to closely mimic that of the assembler layer in a traditional compiler…

If that sounds interesting, you can find a lot more details by reading the full text of the comment.

On the webkit-dev mailing list back in April, there was an interesting thread that Michael Nordman from the Google Chrome team started with a message titled, “AppCache functionality provided by the embedder of webkit” (related to the offline-Web-applications feature in HTML5). Michael begins that message with this paragraph:

I’m working on the app cache for Chrome. We’ve decided to hoist most the functionality provided by the app cache into Chrome’s main browser process, so we won’t be using most of the implementation provided by WebKit. I’d like to work through what changes to make within WebKit/WebCore to allow an embedder pull that off. Any suggestions would be much appreciated.

Darin Adler responded with some thoughts and a question (to which Michael replied) but the discussion about specifics didn’t go anywhere after that (not on the mailing list at least), because in the next message in the thread, Maciej Stachowiak replied to question the general approach — in fact, to question whether the WebKit trunk should be providing mechanisms to facilitate replacements of parts of its own core code:

It’s been a recurring theme for the Chrome team to request hooks to bypass WebKit functionality and replace it with Chrome-specific code that lives outside the WebKit tree. So far this has been mostly for code developed when Chrome was originally a secret project. While we felt it was best to grandfather in the existing carve-outs, in general I believe this is not the best way to move the WebKit project forward. I would not like to see this pattern replicated for newly developed functionality.

Earlier in the same message, Maciej cites a reason why facilitating the proposed general approach can have a potentially negative side effect:

One downside of this approach is that, if the application cache ever needs to change, it may be necessary to make changes to two separate implementations hosted in different repositories. In addition, quality-of-implementation improvements to one version won’t benefit the other.

[…Continued…]

Web/browser-security maven and coder Adam Barth has been working on implementing a content sniffer in WebKit, based on a content-sniffing algorithm that was originally specified in the HTML5 draft, but that’s now specified as a separate IETF draft that Adam is editing and that’s titled, Content-Type Processing Model.

WebKit applications/ports for particular platforms all currently need to rely on platform-specific content-sniffer code outside of WebKit. There are some reasons why it’s a good idea to do things that way — but there are also some good reasons not to; as Adam notes, doing things that way runs the risk of creating compatibility and security differences among various WebKit ports. So implementing a content-sniffer in WebKit itself will eliminate those differences.

[…Continued…]

David Hyatt just opened a new WebKit master feature-implementation bug on June 19th: Implement the HTML5 datagrid. His first comment there:

This implementation may end up being very different from what’s in the spec.

The goal is to create a simpler implementation that can help improve the spec.

The <datagrid> element is a new HTML element in the HTML5 draft standard, with a corresponding DOM interface.

Elliotte Rusty Harold did a writeup on datagrid for the IBM developerWorks site a couple years ago, describing it in these terms:

What distinguishes [datagrid] from a regular table is that the user can select rows, columns, and cells; collapse rows, columns, and cells; edit cells; delete rows, columns, and cells; sort the grid; and otherwise interact with the data directly in the browser on the client.

The <datagrid> spec has been updated since the time when that article was published, but at a high-level, the feature remains the pretty much the same as in that description quoted above.

It’s great to see a browser project finally starting to implement <datagrid>, because it’s a great feature that I think a lot of Web authors and Web developers are going to be very glad to have.