The ViewML Project
The Design and Evolution of the ViewML Internet Browser for Embedded Linux
By Gregory Haerr
CEO, Century Software
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)
Block Diagram of the ViewML Browser
W3C ViewML Browser Application Layer WWWLib
KHTMLView
KHTMLWidget
QT Compatibility Layer
Std C++ FLTK IMLIB Library
X Windows Microwindows
Following is a brief description of each of the modules:
ViewML Browser Application Layer
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.
W3C WWWLib
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.
KHTML View/Widget
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.
QT Compatibility Layer
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.
IMLIB Image Library
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.
FLTK Applications Framework
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.
Summary
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