DOC

The Design and Evolution of the ViewML Internet Browser for ---

By Denise Knight,2014-08-11 00:40
12 views 0
The Design and Evolution of the ViewML Internet Browser for ---

    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

Report this document

For any questions or suggestions please email
cust-service@docsford.com