Konqueror/Embedded: An Open-Source Web Browser For EmbeddedLinux Systems

The Konqueror/Embedded Project is a derivative of the popular KDE browser, Konqueror (http://www.konqueror.org/). The Konqueror/Embedded Project was created with the goal of providing an open-source and standards-compliant web browser and file manager for embedded Linux systems. Both versions of the browser are based on the Qt GUI Toolkit from Trolltech, as is the whole K Desktop Environment. Due to the portable nature of Qt, Konqueror/Embedded runs under Qt/X11 as well as under Qt/Embedded, which is a special version of Qt for embedded systems.

As with Konqueror, Konqueror/Embedded supports full HTML4, CSS1 and partial CSS2; JavaScript (ECMAScript 262); cookies; SSL; IPv6; and full XBEL-compatible bookmark support and management. Documentation, a FAQ and download links to Konqueror/Embedded can be found at http://www.konqueror.org/embedded.html.

Back in November 2000, when the project started, basically only two browsers were available for embedded Linux environments. The first one was ViewML by Censoft. It was, and still is, based on the old khtmlw-rendering engine from KDE version 1.X. At the time of its release ViewML was certainly the most advanced and smallest free browser available. Censoft ported the rendering engine to the FLTK toolkit, added a custom HTTP client implementation and wrote a small graphical interface around it. Today it is still one of the smallest browsers, but it lacks support for popular current web standards.

The other browser was Opera, a commercial product from Opera Software. Opera Software also based their Linux and embedded Linux-based browsers on Qt. While Opera is quite fast, it is not open source.

Therefore, the lack of availability of a free and standards-compliant web browser for embedded systems was the main motivation behind the Konqueror/Embedded Project.

I am the developer on the Konqueror team, and this simplified my choice when deciding on a browser with which to work. The project started by toying around with the idea of stripping down the HTML-rendering component. I started to establish what the main goals and requirements of the project would be.

One static binary was needed, giving the user enough room to optimize the size considerably, without compromising features. Everything the user can access from the big browser should be available in the embedded browser as well. We also wanted to include a graphical interface optimized for small resolutions. Finally, we wanted to avoid forking the codebase of the relevant parts of KDE.

The goal of having one static binary is quite contrary to Konqueror's design. Konqueror has many components, with lots of shared libraries and external communication processes. The difficulty here was less about linking the sources together in one piece and more about making the code actually run in one process. This process had the potential to cut off one of the key features of Konqueror: the nonblocking user interface. That is, no network hangup should lock up the GUI. The solution here was to fork off the networking code (called I/O-Slave) at runtime and communicate with it through a pipe.

The most difficult task, however, turned out to be achieving the fourth goal: no fork of the codebase. A fork in an open-source project is one of the worst things that can happen. Knowing the speed with which the HTML-rendering engine and the JavaScript implementation develop, a fork would simply have been a nonsense decision, design-wise.

So I tried to find an approach that would allow me to use as much of the original sources as possible, without any modification, so I could easily update them to the latest development version. The search resulted in a fundamental design decision for the project: make the copying of the original khtml, javascript, ssl, etc., sources to the Konqueror/Embedded build process a part of the actual build process.

So it all started with the attempt to make this code compile and work. Of course only the really necessary sources are copied over. For a lot of classes, simplified versions have been written. There is no need to implement the level of generic functionality that code in kdelibs needs in order to support many hardware and software platforms, environments and standards. Quite a bit of code can be eliminated once one accepts the fact that it only needs to run inside an embedded environment.

An example of this reduction can be found in the JavaScript implementation, with support for a property-of-the-screen object called availLeft. It represents the left-most x coordinate on the screen, available for application windows. In KDE this value can be queried from the window manager using the NET standard. It is not necessarily zero but can be constrained by a panel or any other client changing the work-area geometry. In an embedded environment with, for example, a touchscreen running a limited resolution and applications always running on full-screen windows, it is safe to simplify this code to always return zero. This simplification, however, cannot be done by simply modifying the JavaScript implementation, as it is copied from the original KDE source tree. Any change to it would get lost the next time the build process starts. The actual code retrieves the values for this and related properties, such as availTop and availWidth, from a class called KWinModule. So I needed to write a class capable of doing what the original KWinModule class did. This new class is surprisingly simple, while still acceptable as a drop-in replacement. The only necessary method is the one and only method of returning the work-area rectangle, which contains the values for those JavaScript properties:

#include <qapplication.h>
class KWinModule
{
public:
    KWinModule() {}
    QRect workArea()
    { return QApplication::desktop()->rect(); }
};

A lot of code needed to be written, along with parts that needed a far more complex rewrite. For example, the cookie manager in KDE runs in a separate process, and it talks with the I/O-slaves--those are small processes doing only the I/O work for listing directories or retrieving files from the Web--over the DCOP (desktop communications protocol) interprocess communication mechanism. In Konqueror/Embedded these I/O-slaves also run in a separate process that is forked from the main process. It is not possible to use the real DCOP though, because it depends on the X11 ICE library. Independence from the X11 system is mandatory. Thus, a simplified version of the interprocess communication mechanism needed to be written. This version is specialized and limited to message exchange through pipes between the main process and each forked I/O-slave process.