Using GTK+/X as an Embedded GUI

Consumer embedded devices require a graphical user interface (GUI) tailored to specific device characteristics. To offer a handful of examples:

A major factor in the success of Palm Pilots is a user interface (UI) paradigm designed to fit the Palm device. The plain widget look provides on-screen simplicity, the menu system offers a good compromise between offering user options and optimizing screen real estate, and the applications are designed around stylus input. One of the reasons why WinCE and Palm-sized PC devices have not done very well is that a general-purpose GUI design borrowed from desktop paradigms is not appropriate for embedded devices.

There are several embeddable GUIs for Linux, including Qt/Embedded, FLTK and GTK+. Which toolkit should a developer use? How much engineering effort is needed to tweak to spec? What footprint will this require?

This article describes our experience designing and implementing a custom GUI for a consumer Linux device. We decided to use GTK+ running on the X Window System. It took five engineer-months to produce our rock-stable, customized and reduced-footprint GUI totaling 2.9MB (including X).

We designed a custom UI to match our device's I/O characteristics. Our device has a small, low-quality screen and no mouse. A row of softkeys under the screen provides primary user input (see Figure 1). The bottom 14 pixel region of the screen is reserved for displaying monikers above softkeys; this is the softkey bar.

Figure 1. Device Mockup

Rather than create new paradigms that would confuse users, the rest of the UI is drawn as a typical point-and-click interface, complete with buttons and scrollbars. We maintain the user's control metaphor of physically "pushing" widgets by substituting push-via-softkey for point-and-click. Each button is arranged horizontally with an arrow dropped under it that extends across the window border into the softkey bar. Figures 2-5 show the elements of our UI design, including buttons.

Figure 2. Buttons extend an arrow into the softkey bar. While pressed, the button and its arrow are filled with gray.

Figure 3. Text-entry fields use a boldface font for the label and a plain-face font for the user's text. This uses minimal screen real estate to differentiate between the two elements.

Figure 4. Scrollbars visually fit into the scrolled panes they control, giving an uncluttered look.

Figure 5. Application windows and dialogs are shaped and drawn with different title bar designs. The topmost window gets the softkey bar.

After hammering out this draft UI design and testing innumerable mockups, we heaved a collective sigh of relief. Our device would be usable. Our glee was cut short with thoughts of actually putting the UI together. We conscientiously had avoided considering implementation when drafting this UI. What programmer in his or her right mind would want shaped windows, arrows spanning different widgets and a myriad of fonts? Now it was time to pick a GUI, roll up our sleeves and get to work.

We chose to use GTK+ 1.2.8 running on the X Window System, in turn running on a framebuffer. While both GTK+ and X are often considered to be bulky desktop-only solutions, they are sensible choices for embedded devices for the following reasons:

C vs. C++ on Embedded Devices