Choosing a GUI Library for Your Embedded Device

I will not go into detail about the implementation of my application, as it is not within the scope of this article. However, to summarize, Qtopia is C++-based, and I think the Qtopia designers have a good grasp of the idea of C++. As is no surprise, all widgets are objects, and to have standard functions (methods) in your own widgets (defined in your own class), you inherit from base classes.

The different objects (widgets) need to communicate. For example, if I click on a button, the button object might want to tell the text field object to update the text. In Qt, and thereby Qtopia, this is done using signals and slots. They are simply standard methods with an attribute. This interface makes it possible to make the objects independent of each other. The button just sends a signal, “clicked”, the text object has a slot “update”, and they compile and work fine without each other. Then, when I put them together in my app and give the connect (obj1, clicked, obj2, update) command in the initialization to connect signal clicked with slot update, the magic happens. The text is updated when I click the button.

Those connections even can be made automatically, simply by giving them the right name. If I have a widget named cancelBtn, with the signal clicked, and I make a slot named on_cancelBtn_clicked, the clicked signal from the cancelBtn is automagically connected to this slot. This signal/slot design makes the code easy to read and maintain. On the other hand, if you are not familiar with signals and slots, and you look at someone else's code, you can go on a wild goose chase looking for the calling of the slot (method) for a long time.

So far, the documentation has been a great help. They have done a great job writing the documentation of the API. However, the API documentation does not help you if you don't know what API call you should use for a task. I spent a lot of time making the drawing object work correctly, because I had to collect the information from different places in the documentation. I never found an efficient way to make my scrolling graph. I did not find any bitmap manipulation that would scroll my heartbeat graph, so I chose to repaint the whole thing for every scroll step. There might be an easier way, but I did not find it.

Therefore, if you want to do more advanced programming in Qtopia, you need to find a good book or guide to complement the API documentation.

Figure 1. The Application Built with Qtopia

Nano-X was formerly known as Microwindows. Why the change of name? Take a wild guess. If your guess includes a lawyer, you are probably on the right track.

Nano-X is an open-source project at Nano-X.org, started and still headed by Greg Haerr. Nano-X is licensed under the MPL license. The MPL license allows you to create closed source drivers and applications. But, the Nano-X source itself must stay open. There is an option to use the GPL license, if desired.

The Linux package from Mechatronic Brick includes the Nano-X library, but this version did not include support for PNG pictures. I needed PNG support, so I had to recompile. This was quite easy after I found out what config file is used when building in the Mechatronic Brick setup. I noticed that Nano-X comes with a config file that set up Nano-X to be built with TCC, a small and very fast C-only compiler. I decided to use this too, and then the library was compiling in no time.

Starting to program in Nano-X is quite a change, especially when coming from the nice and polished C++ classes of Qtopia. Nano-X is so much simpler, which leaves a lot more work for the application programmer.

Nano-X does not have widgets, or buttons or combo boxes—only windows. There are libraries to put on top of Nano-X that will give you more features, such as Nano-X's own reimplementation of the win32 library and the Fast Light Toolkit (FLTK). In this article, we delve into the basic part of Nano-X.

Basically, when programming for Nano-X, you do four things:

A typical standard application window is made of a base window with the frames and the small x close button (of course, there are options to customize this look). Subwindows act as buttons and display fields. Yes, in Nano-X, a button is declared like a subwindow with the mouse-click event selected.

In Qtopia, I simply made a class, connected some signals and slots, and puff, the magic happened. In Nano-X, I had to take care of things myself. A central part of a Nano-X application is the event loop, typically a for (ever) loop containing the get event function and a case structure to handle the event (see Listing 1 for an example). When I get a mouse-click event, I ask which window captured this event and act from that. This means that the single button is not isolated in its own piece of code, but weaves into the app. The basic function of the button or the display field should of course be in a function by itself, but the event loop must be aware of which events are selected in the button and what to do with the events.