Developing Handheld Applications Using Linux and Qt/Embedded (Version 1.1) Jukka-Pekka Suominen Department of Computer Science Åbo Akademi University, FIN-20520 Åbo, Finland e-mail: [email protected] ACM classification: C.5.3 Microcomputers, D.2.6 Programming Environments ACM Special Interest Group: SIGMOBILE

Abstract This paper describes software development for handheld devices running Linux, using the Qt/Embedded (QtE) toolkit. Developing software for handheld devices, such as PDAs, differs in many ways from “ordinary” software development because of the different applications and limitations of the target hardware. By using Linux, a scalable and robust operating system with excellent networking capabilities, and QtE, a small but highly featured C++ toolkit, high-quality applications can be developed despite these limitations.

Contents ABSTRACT ......................................................................................................................................................... 1 1. INTRODUCTION ........................................................................................................................................... 3 2. CONSIDERATIONS FOR HANDHELD DEVELOPMENT ..................................................................... 4 3. LINUX IN HANDHELDS............................................................................................................................... 5 4. THE QT/EMBEDDED TOOLKIT ................................................................................................................ 6 5. THE DEVELOPMENT ENVIRONMENT AND DEVELOPMENT TOOLS........................................... 8 6. APPLICATION DEVELOPMENT WITH QT/EMBEDDED .................................................................. 10 7. SUMMARY.................................................................................................................................................... 13 8. REFERENCES .............................................................................................................................................. 14

2

1. Introduction Mobile computing and handheld devices are becoming increasingly popular due to technological advances that allow the manufacturing of smaller and more powerful devices. The functionality of these devices vary from highly specialized, such as mobile phones and portable GPS receivers to very general handheld computers. This paper will focus on these handheld computers and the software development for them. Mobile computing presents developers with exiting possibilities due to its extreme portability (portability as in mobility), but that portability comes at a price. These devices lack the raw processing power and visual display capabilities of their desktop counterparts. Although the processor speeds have gone up from a meagre 8MHz to 400MHz in today’s top range PDAs, it’s still a far cry from what desktop computers can perform. Handheld Computers

Desktop Computers

Processor speed

400 MHz

2800 MHz

RAM

64 MB

< 1024 MB

Storage space

48 MB Flash ROM

< 100 GB Hard disk

3.78” 240x320 pixels

< 21” 1600x1200 pixels

65000 colours

32 mil. colours

Touch screen / stylus,

Mouse, keyboard, drawing

micro keyboard

tablet etc.

Screen size Input devices

Table 1 – Feature comparison between Compaq iPAQ and a top range desktop computer As can be seen from this table, the most limiting factor in handheld computers is the available storage space. This gives that the operating system and the applications must be small, yet the limited input devices call for graphical user interfaces. To meet these demands many PDA manufacturer has adopted Linux as the operating system and Trolltech’s Qt/Embedded as the user interface development toolkit. Linux is a scalable and robust operating system with excellent networking capabilities, and most importantly, it can be made very small in size, yet retaining critical functionality. Qt/Embedded is a small, yet powerful cross-platform C++ GUI toolkit that also provides added functionality, such as

3

networking and database connectivity. QtE can also function without an X server, using a framebuffer device instead, thus further reducing the size and power requirements.

2. Considerations for handheld development When developing software for a handheld computer, you need to take into consideration a variety of things that can be largely bypassed in desktop development. Some of the main issues are the user interface and the rather limited permanent storage space. These two things will probably have the largest influence on the development process, but there are other factors to consider as well. The available memory and processing power sets its limits, as well as the fact that the device is most likely battery operated, so low-power considerations come into play as well. The developer should strive to find a proper balance between these issues when designing the software. In most cases, the user interface is the part that needs most consideration. Since the screen size on handheld devices is rather small, and often has different proportions than a conventional computer screen, and the input devices are usually limited to a trackpad-button combination and/or a stylus or a touch screen, care must be taken to provide the necessary functionality. These input devices are not as precise as a mouse or a drawing tablet, nor do they have the same functionality (e.g. multiple mouse buttons) so the user interface must be clear and uncluttered to remain user friendly. Although some handhelds might provide the user with more advanced input devices, the user interface should still, in the name of portability, be designed in a way that allows it to be used with less capable devices. It is recommendable to design the applications with the stylus/touch screen user in mind, and use the “advanced” input features to provide menu shortcuts or other similar functionality. The fact that the available storage space is rather limited has some implications on the applications as well. Applications should avoid permanently storing data on the device unless specifically requested. An email application, for example, should not automatically download and store all messages from the mail server, but e.g. instead only retrieving the headers and presenting the user with the subjects of the messages, which could then be downloaded and stored on demand. This also means that applications should account for the fact that some data might not always be available, but is instead stored on some remote location, e.g. a

4

desktop computer. In this case, the application should alert the user to this, and perhaps suggest its retrieval. The available memory and processing power sets of course its own limitations on the applications. Because handhelds are quite limited in their processing capacity, the applications should be designed with this in mind. This means that some resource hungry applications are not very suitable for these platforms. Instead, the design should focus on “lean and mean” personal utilities, which are much better suited for handheld computers. If the design absolutely calls for processor intensive calculations, the developer should consider doing these calculations remotely on a more powerful computer. The handheld device would in this scenario function as a device for gathering data and then presenting the results of the processing. In delegating the more resource needing parts of applications to remote servers, the handheld device can focus on tasks that it is better suited for. Limited battery power is also something that differs handhelds from their desktop counterparts, but this is usually something that the application developer does not need to consider. The power management is done at system level, and should be transparent to the applications. Of course, the use of unnecessary CPU cycles (busy waiting, superfluous eyecandy, etc.) should be avoided. Also, applications should react properly to a low power situation (if the underlying system provides a way to warn the applications of this) by saving open files and writing their data to the permanent storage. Other than this, there is not much else that can be done from a power management perspective.

3. Linux in handhelds The choice of an operating system for a handheld computer will be influenced by the limitations imposed by the target platform. Since memory and storage space are rather limited, we cannot simply use whatever operating system we like. There are several operating systems designed to fit handhelds, but the focus of this paper will be on Linux. Although a modern Linux distribution will need up to 4 GB when doing a full install, the modular design of the system allows it to be scaled down by orders of magnitude. For example, OpenZaurus, a Linux distribution designed for the Sharp Zaurus, and which is

5

being ported to many other handhelds, needs only 897 KB for the boot image. This includes a fully functioning Linux distribution with network and graphics support. This is actually where Linux really excels. It provides a robust base operating systems with all the features needed for modern systems. Linux has excellent networking capabilities, which are much needed when connecting to desktop computers for syncing and of course for Internet use, and although the normal graphics system, X Window System, is very resource hungry, Linux offers also other means to use graphics. The most common solution in embedded Linux distributions is to use the so called framebuffer device, i.e. writing data directly to the video card’s memory. Although this is not as flexible and scalable as the X Window System, the lack of some advanced features is rarely missed on handhelds and other embedded systems. Instead, the ability to fit a functioning graphics system into a 897 KB boot image rather than the minimum of 5 MB for the standard X is what is needed for these small devices. There are other benefits in using Linux as well. It is a cross-platform operating system, and ports exist for dozens of different processor architectures, with more to come. Also, since it is an open source system, it means that (in theory) you can do the porting yourself. This also means that the initial software costs are very low, or even non-existent, since much or all software can be freely downloaded from the Internet. And although some companies seem to think that that the use of open source software means that no proprietary software can be developed, this is false. Linux also comes with a variety of excellent development tools, which makes it an even more attractive alternative. High quality compilers and cross-compilers (GCC) and other tools (make, configure) combined with excellent toolkits and libraries makes software development for handhelds as well as desktop computers easy and efficient.

4. The Qt/Embedded toolkit The Qt/Embedded toolkit is a port from Trolltech’s Qt C++ API targeted for embedded and other small computer systems. QtE is a cross-platform GUI toolkit, so it runs on a variety of hardware platforms, but it is most commonly used together with embedded Linux

6

distributions. What differentiates QtE from the standard Qt toolkit, is that it is meant for platforms with little available memory. QtE doesn’t need an X server or Xlib, and thus reduces the memory footprint dramatically. Since QtE is a modular open source toolkit, it can be customized to include only the features that are necessary, enabling it to be sized down to as little as 800 KB. (An all-inclusive QtE install needs ca. 4 MB of space.) This combined with an embedded Linux distribution means that the total size of the system can be under 2 MB. QtE offers also Java integration, meaning that it can capture the Java VM’s AWT calls and direct them to the Qt rendering engine instead of Xlib. This enables developers to use Java as well as C++ when developing applications. Although QtE is a graphics toolkit, it provides also much non-graphical functionality, such as networking and database integration.

Qt/Embedded vs. Qt/X11 on embedded Linux (source: www.trolltech.com) The QtE windowing system consists of one or more processes, one of which acts as the server. No added code is needed for an application to run as the QtE server, just starting the application using the –qws command line option will take care of it. The server process takes over much of the functionality normally associated with the X server, including allocation of window regions and generating input events. The clients communicate with the server using shared memory regions, but the communication is kept to a minimum by making each client responsible for drawing its own widgets and decorations, such as title bars. The programmer need not worry about these details, though, since it is all handled transparently by the QtE libraries. The clients can communicate with each others using asynchronous message passing through the QCOP channels by sending and/or receiving pre- or user-defined messages connected to different “slots”. QtE supports three common font formats, in addition to its own pre-rendered font format (QPF). By converting all necessary fonts to the QPF format, support for the additional formats can be compiled out, thus reducing the total memory footprint even further. Since

7

full Unicode font sets take up a considerable amount of space (typically up to over 1 MB), it is possible to select and store a custom subset of the whole font set. QtE also supports several input devices out of the box. All common mouse protocols (such as BusMouse, IntelliMouse and Microsoft) are supported along with other input devices, such as touch screens. If support for a custom pointer device is needed, this can be easily added by sub-classing the existing mouse handler classes. Finally, the fact that QtE is a cross-platform toolkit, means that developers can with little or no extra effort ensure that their applications function on different platforms as well. In most cases, just a simple recompile for the target platform is all that is required when porting QtE applications.

5. The development environment and development tools Linux is an excellent development platform for QtE application development, mainly because it includes several useful tools for cross-platform development. This means that QtE development can take place using the common development tools, like GCC, KDevelop and the likes. Actually, most of the development can be done using the standard Qt/X11 libraries, since they are essentially interchangeable. A normal QtE development environment under Linux consists of 6 parts: •

Standard development tool chain.

•

Cross-development tool chain.

•

The integrated development environment (such as KDevelop) or alternatively any preferred text editor.

•

The Qt meta object compiler (MOC)

•

The QtE specific tools qmake and QtDesigner. (Not strictly necessary.)

•

The virtual frame-buffer. (Not strictly necessary.)

The development (and cross-development) tool chain consists of several parts. The most common option is to use a GNU C++ compiler (g++), libc, QtE or Qt/X11 and other necessary libraries, and the standard binary utilities, along with a cross-compiling version of

8

these for the target platform. Cross-compiling is often necessary because of the limitations of the target platform. Handheld devices usually lack the processing power and storage capacity required for native compilations, not to mention that actual coding would be nearly impossible. The use of a cross-compiling tool chain allows the developers to use their preferred editors or IDEs as well, thus eliminating the need to learn to use a new tool. Qt comes with some very useful cross-platform development tools, of which the MOC is essential for QtE development, since it compiles the QtE extensions (signals and slots, for instance) into standard C++ code. The MOC reads the application’s header files and generates the code needed to implement the signals and slots. The MOC also supports the Qt translation mechanism, property system and run-time type information. This part of the development process is transparent to the developer, in the sense that there is no need to edit, or to even look at the generated code, and if the developers are using qmake, Qt’s makefile generation tool, the created makefiles will include rules to run MOC when needed. The use of qmake is heavily recommended, since it not only takes care of the MOC compilation, but it also allows generation of cross-platform makefiles, thus making it easy to switch between different configurations. The QtE development environment includes also the QtDesigner, a rapid application development tool, which allows developers to graphically create user interfaces instead of having to manually code them (which is of course possible, if desired). Using QtDesigner, developers can quickly design the necessary interfaces and dialogs (prompting for filenames etc.) and concentrate on the real functionality of the application. QtDesigner stores the interface design in a human readable .ui file, which is then converted into C++ by the UIC (user interface compiler). Again, the developers do not need to manually run the UIC, but qmake automatically includes the necessary rules in the generated makefiles. Another possibility is to have the applications import the .ui files and generating the user interface at run-time. This allows users of the application to modify the interface without actually having to recompile the application. This can also be used to save permanent storage space by reducing the size of the applications. The downside with generating user interfaces at runtime is of course the longer loading times of applications.

9

One benefit when using Linux as the development platform is the existence of the virtual frame-buffer. It is an X11 application that simulates the frame-buffer device on handhelds. The developers can specify the virtual frame-buffers width, height and colour depth and get an identical, pixel for pixel representation of the screen on the physical device. This saves time, since the developers can test the application on the development platform, instead of having to continuously update the software on the handheld device for testing.

6. Application development with Qt/Embedded The heart of QtE application development lies at the creation and interconnection of widgets. Widgets are the graphical components of the application, e.g. buttons, scroll bars, menus etc. Widgets are instances of QWidget or one of its subclasses. User-specified custom widgets are created by subclassing. Widgets are organized in parent/child hierarchies, and a widget may contain any number of child widgets. These child widgets will be displayed within the parent widget's area. A widget without a parent is a top-level widget, i.e. a window, and is automatically decorated with a configurable frame and a title-bar. There are no arbitrary limitations imposed on the widgets, meaning that any widget can be a top-level widget, and any widget can be the child of any other widget. The placement of child widgets within the parent's area can be set either manually, or automatically using so called layout managers.

An extract from the QWidget class hierarchy (source: www.trolltech.com) A GUI application needs to somehow respond to the users actions involving these graphical components, e.g. when a user clicks a button, some action is taken. QtE uses a method of signals and slots in the interconnection of widgets. Actually, any class derived from QObject can use signals and slots, so it is not strictly bound to the graphical components of the application. Using signals and slots instead of callbacks, that are widely used in other toolkits, has several advantages. Signals and slots are faster, flexible (meaning that the

10

objects connected together need not to be aware of each other), type-safe and are implemented in C++ as fully object-oriented components. The use of signals and slots is easy and effective. A QtE widget emits a signal when some event occurs, e.g. clicking on a button will make the button emit a ‘clicked’ signal. The programmer can then create a function (which in this case is called a slot) to process that signal, and then call the connect() function to connect the signal to the appropriate slot. This means that the classes need no knowledge of each other, which leads to easier reuse of code.

An abstract view of signals and slots connections (source: www.trolltech.com) QtE comes with many predefined, ready to use widgets, such as labels, pushbuttons, checkboxes, scroll bars, progress bars etc. It is also easy for the developers to create their own widgets when necessary. When creating a custom widget, it must be derived from either QWidget or one of its subclasses. If the widget will be displayed on screen, it needs to define a paintEvent() function to specify what needs to be drawn when the widget is displayed or otherwise needs to be redrawn. The developers may wish to declare handlers for other events as

well.

There

are

over

fifty

types

of

events,

such

as

MouseButtonPress,

MouseButtonRelease, Resize, Paint, Close etc. It is not necessary to declare handlers for all events, only the ones needed for the correct functionality of the widget must be declared. Custom made widgets can also be used from the QtDesigner for rapid application development.

11

QtE is not only a GUI toolkit, but it provides much non-graphical functionality as well. QtE contains classes for input/output, networking, database interaction, threading and data containers. The input/output features include classes for reading and writing text and binary data streams to/from files, buffers, sockets or custom devices. They can also be used for serialization of basic C++ and many Qt data types. Also included is network transparent access to files and directories using either FTP or HTTP, and support for other protocols can be added. There are also classes for reading and writing images (GIF, PNG, JPG etc.), and a W3C compliant XML parser. The networking classes on the other hand provide more low level networking functionalities for writing TCP/IP capable applications. The QSocket class provides asynchronous buffered TCP connections that do not block the application. Instead the socket emits a signal when there is data to be read on the socket, which can then be connected to an appropriate slot for reading. The database interaction is provided by an additional module which must be enabled when compiling QtE. It provides a uniform, platform and database independent interface for SQL transactions. Any QtE widget, including custom widgets can be made database aware, and QtE also comes with a set of ready made widgets for database transactions. Since many GUI applications are multi-threaded, QtE provides threading functionalities as well, although this is also a compile-time add-on module. There are four classes for creation and synchronization of threads: QThread, QMutex, QSemaphore and QWaitCondition. The data containers in QtE are very similar to those in the standard template library in C++, but they are more efficiently designed to fit the requirements of embedded systems.

12

7. Summary The available hardware in handheld computers sets it limitations on the software as well. A small, yet robust and functional operating system is needed, as well as an effective and small application development toolkit to allow high quality end user applications to be written. Linux and Qt/Embedded fit this category perfectly. Linux is a very robust operating system with excellent networking capabilities and it can be scaled down to fit the space requirements of embedded devices. It is also open source, which means low costs and extreme portability of both the operating system and the applications as well. Qt/Embedded is a very highly featured C++ GUI toolkit that allows development of high quality applications. Qt/Embedded is also not only small in size and power requirements, but open source as well, although commercial versions also exist. Application development using Qt/Embedded and the tools provided with it, such as QtDesigner, is fast, easy and effective. The main points in Qt/Embedded applications are widgets and their interconnection using a mechanism of signals and slots. This provides a safe, fast and easy way for the objects to communicate together without the need of error prone callbacks. Widgets react to events by emitting signals, which can then be connected to different slots for processing. Qt/Embedded comes with a variety of ready made widgets with different signals and slots, but the developers are free to create their own customized widgets to fit their needs. And since Qt/Embedded provides developers with many non-graphical classes as well, almost every kind of application can be written using it. These benefits have been noticed by many developers around the world, and companies and organizations such as Sharp, Compaq, NASA and many others have chosen Linux and Qt or Qt/Embedded as their development platform. Linux has also became increasingly popular especially in the embedded systems market, and it might very well become the most widely used operating system in embedded devices.

13

8. References •

M.K. Dahlheimer: Programming with Qt (2nd edition), O’Reilly, 1992.

•

J. Epplin: A developer’s perspective on Sharp’s Zaurus SL-5000D Linux/Java PDA, LinuxDevices.com, 12.11.2001. (http://www.linuxdevices.com/articles/AT6553340334.html)

•

J. Epplin: Exploring Linux PDA software alternatives, LinuxDevices.com, 23.2.2001. (http://www.linuxdevices.com/articles/AT3058975992.html)

•

C. Hollabaugh: Embedded Linux – Hardware, Software and Interfacing, AddisonWesley, 2002.

•

R. Lehrbaum: Using Linux in Embedded Systems and Smart Devices, LinuxDevices.com, [undated]. (http://www.linuxdevices.com/articles/AT3155773172.html)

•

R. Lehrbaum: The Embedded Linux GUI/Windowing Quick Reference Guide, LinuxDevices.com, 1.6.2002. (http://www.linuxdevices.com/articles/AT9202043619.html)

•

Trolltech: Qt/Embedded, LinuxDevices.com, [undated] (www.linuxdevices.com/products/PD9968824320.html)

•

Trolltech: Qt/Embedded Whitepaper, www.trolltech.com, [undated]

•

Trolltech: Qtopia – a Qt-based mobile palmtop environment, LinuxDevices.com, [undated]. (http://www.linuxdevices.com/products/PD8467855387.html)

14