The Design and Evolution of the ViewML Internet Browser for Embedded Linux

By Gregory Haerr

CEO, Century Software Embedded Technologies

The embedded Linux market is rapidly expanding, but poses unique challenges: While being driven primarily by the open source software movement, embedded applications typically run in a resource restricted environment. Most open source software development has occurred for the desktop, where large hard drives and hundreds of megabytes of RAM abound. Additionally, embedded systems aren’t frequently rebooted or field-upgraded, so the maintainance and quality of the software are big concerns.

Leveraging the last 7 years of desktop software advances, while keeping ram and rom usage in check are key issues in any embedded design.

The evolution of the desktop Internet browser has grown to be quite a family, with over 20 browsers available in some form or another. Why design another browser? After looking at almost all of the browsers available, with the intent of selecting one best suited for the needs of embedded environments, we found that there wasn’t a single package that would work. Either the browser was huge, like Netscape’s Mozilla, and would never run on most embedded systems, or too small, with very incomplete HTML parsing. So we decided to design a new browser, one that was specifically targeted at the needs of the embedded Linux community.

The initial design goals for the project were:

Create the smallest browser possible, but still retain 100% standards compliance for HTML parsing. The browser would be used in many applications from embedded-device documentation display to Internet appliances and set-top boxes. We had to make sure that the browser always displayed pages correctly.

Use available open source code for the HTML parsing and display engine. We didn’t want to get in the business of writing an HTML engine from scratch, which is the mistake made with most smaller browser implementations. It takes a lot of knowledge and experience to display all the HTML language quirks correctly, especially since so much HTML is still written by hand.

Use the selected HTML widget code as-is. We didn’t want to change any of the core HTML display engine code, even though it is open source. This bought us two major benefits: the ability to upgrade the HTML display capabilities as the original parsing engine is enhanced by HTML experts. It also meant that no bugs would be introduced directly in the core display routines, keeping the quality high.

Use the Fast Light Tool Kit (FLTK) applications framework for the user interface. FLTK is available at www.fltk.org, and provides a set of user-interface widgets ideally suited for small environments.

Run on both Microwindows and the X Window System. In order to gain large acceptance, the browser would need to run on the standard X Window System as well as the ideally suited newer Microwindows graphical windowing environment (www.microwindows.org). In addition, we wanted to make sure that the selection of either windowing system was seamlessly integrated into the software design, and didn’t adversely affect the architecture.

The first major decision was selecting the open source HTML parsing and display engine. We chose the KDE 1.0 HTML widget from KDE desktop’s kfm file manager. (KDE is available at www.kde.org). This naturally raised many questions, such as:

Why not KDE’s newer v2.0 Konqueror widget?

QT is HUGE! (and not available on Microwindows)

What about Mozilla and it’s gecko engine?

Here’s some of the thoughts we had during this process: The KDE 1.0 HTML widget displays a vast majority of web sites correctly, which we tested by running the desktop kfm file manager. It works well, supports full HTML v3.2, is relatively small, and is coded in a style that permits easy reuse of code. So why not use the KDE 2.0 widget which has support for HTML 4.0 and JavaScript 1.4?

The KDE 2 Widget was at the time coding started, far too feature-lean and unstable to use in a working project. It is much better now, but still far from proven. The KDE 1.0 widget has been out for over a year.

The KDE 2 Widget is approximately four times large than it’s 1.x counterpart. We thought that for the first version, the feature/size tradeoff was worth it, especially since the design allows the newer widget to be dropped in after it’s development and quality solidifies.

The KDE 1.0 Widget’s use of the QT widget set was by far the largest issue when considering which Widget to use. (QT is available from www.trolltech.com) However, it presented itself as a logical choice for use in this project for several reasons:

QT, while not available on Microwindows, was coded in a style that permitted the easy replacement of classes with re-implemented versions running on top of another toolkit that was available on Microwindows and X. This reduced the overall size of the QT API (as we didn’t need all the classes) and allosed its use.

A free version of QT was available as a reference code base (Harmony). While no code from this project was actually used, it was useful to examine another implementation of the API.

The only widget set that runs on both Microwindows and X is currently FLTK. This toolkit is also coded in C++ with some similar concepts present in its design. This permitted the relatively easy integration of the QT API with an FLTK backend.

Mozilla was considered briefly for use, simply because of the huge movement behind it. However, there were many objections that prevented it being a serious contender: Mozilla is huge. The GTK+ widget version of Mozilla (without mail, news, etc.) weighs in at a hefty 12 MB without loading a page. That is six times larger than the current ViewML browser. The GTK+ widget set is also large, at least 2MB compared to 100k for FLTK.

After finalizing the selection of the core display engine, we created a layered software architecture that strictly defined each of the browser’s components, and exactly what they would do. The layered architecture was required in order to meet the design goal of leaving the display engine code untouched. We also had to define a number of new modules, with the idea that each could be replaced if a smaller module was created, or required changes as the result of the graphical windowing system being used.

(more)

Following is a brief description of each of the modules:

This thin layer is written entirely in the C++ FLTK applications framework, and provides the basic graphical user interface layout. We tried to keep this layer thin so that applications engineers can easily modify the ViewML browser for custom suited embedded environments without having to require much knowledge of the whole browser. In some embedded environments, there might not be a user interface at all, but instead just a full-screen browser page displayed. This layer also deals with all network and local file access.

The World Wide Web Consortium’s WWWLib Library was chosen to perform all asynchronous network i/o and HTTP get functions, as it was easy to use. Ultimately, we feel this library is larger than is required and will probably be rewritten in the future. For now, however, it allowed us to get the initial browser version functional quickly, without having to concentrate on this specialized area.

These two modules comprise the original unmodified KDE 1.0 HTML Widget code. This unmodified source code is called from above by the user interface applications layer and thinks it’s talking to a QT applications framework below. The KHTML Widget handles all the HTML parsing, drawing and basic layout. It does not directly handle scrolling or frames; it delegates those tasks to the KHTML View. The KHTML View is the most fully-featured widget in ViewML. This is a QT-based widget that contains the KHTML Widget. KHTML View manages one or more KHTML Widgets, and also implements scrolling and HTML frames.

This layer provides the "glue" that interfaces the unmodifed HTML Widget with the FLTK applications framework, rather than the QT framework. The C++ QT classes were rewritten in this layer, keeping the same public interfaces. These classes include graphical widgets (edit controls, buttons, etc.), collection and string classes, and general functional classes that implement some particular QT feature (such as signals).

For all graphical classes, these were implemented using the functionality provided by FLTK. This allowed the relatively easy implementation of all standard controls and most drawing functions. However, the non-standard QT mechanism of signals, which are used for inter-widget communication, had to be coded from scratch.

For all the collection and string classes, these were implemented on top of the Standard C++ Library. These classes include stacks, lists, dictionaries (hash tables), and the always-present string class. These classes were fairly standard, with the exception of the novel auto-deletion mechanism QT uses in its collection classes.

For images, IMLIB from the GNOME project (www.gnome.org) was used for the X Window System. This allowed the implementation of the QT style of images, which includes the ability to auto-detect the image type, auto-scaling of the image, and displaying images on the screen. There are several disadvantages to this library, such as size, but the main objection is it’s unavailable for Microwindows. For the Microwindows environment, we chose to add graphics image support directly into Microwindows, which worked out well because we kept the size quite small and have allowed for additional image decoders to be easily added.

Two different versions of the FLTK applciations framework are used, depending on the windowing system used. Standard versions of FLTK include support for Win32 and X. Folks from the Microwindows project as well as ourselves ported FLTK to the Nano-X API available in Microwindows. This support allows client/server interaction with the Microwindows server, just like the Xlib model. Choosing FLTK is a great choice, since both FLTK and Microwindows support the X Window System. This allows the ViewML browser to be debugged or enhanced on the Linux desktop, using either the X Window System directly with FLTK, or running the Microwindows server on top of X. In this way, the exact characteristics of the target environment, whether running Microwindows or X, can be emulated. The Microwindows system allows the exact display characteristics of the target device to be emulated on the desktop, which allows designers to model a gray scale target on a color desktop, for instance. We also like the idea of being able to run almost the identical code paths on the desktop as the target device, which greatly improves quality control.

The ViewML Project has produced a high-quality web browser in a short amount of time, directly targeting the embedded Linux environment. By including core open source components we’ve been able to use a high-quality display engine while keeping the overall RAM and ROM requirements quite low. Currently, the ViewML browser runs in about 2MB of RAM while having a codefile size of around 800k. Combined with Microwindows, the entire environment can run in less than 2.5MB RAM, which allows it’s use on most 32-bit embedded Linux systems running graphical displays. By placing the entire project into open source, we feel that other contributors will get involved, and ultimately, the problem of having a high-quality web browser for the embedded Linux environment will be solved.

Century Software’s web site is embedded.centurysoftware.com

The ViewML Project’s web site is www.viewml.com