Introduction

Maemo is based on Debian GNU/Linux operating system which itself inherits its architecture from the Unix operating system. Linux, GNU and Debian are open source projects (or project umbrellas for multiple separate projects) which embrace sharing of source code, collaboration and open development model. Maemo promotes these values as well by providing an integrated open source based platform for mobile devices, by sharing source code, and by contributing code directly to the upstream projects.

Key Technology Selections

Key Components

Maemo is based on the Linux operating system kernel. Linux is a monolithic kernel that supports multiple hardware platforms and is scalable to be able to support wide range of different kinds of devices from wrist watches to large server systems. Currently all maemo based devices have OMAP chipsets which contain a general-purpose ARM processor and a DSP unit. Maemo devices run recent 2.6 kernels.

The user space software links with the standard GNU C library interface. The GNU C library comes with all major Linux distributions except some minimalistic embedded systems which use some other size optimized C library (like uClibc). The GNU C library aims at POSIX compatibility and maemo aims at being compatible with mainstream Linux systems as much as possible to minimize the effort of porting applications and application engines and to bring in the best open source solutions for mobile computers.

The package management framework, the file system hierarchy, and general design policies come from the Debian distribution. Maemo aims at following Debian policies as much as possible. Debian distribution has by far the largest development community; in September 2007 Debian supports about a dozen different hardware architectures and it has more than 18,000 software components available.

The user interface architecture is based on GNOME framework, GTK+ widget set especially. GNOME is a leading application framework for desktop Linux systems. Unlike its competitor KDE, GNOME allows building proprietary software on top of its core libraries without any license payments. From GNOME project maemo has inherited many central components including GTK+, GStreamer multimedia framework, GConf configuration management, and XML library, for instance. Maemo extends GTK+/GNOME by providing the Hildon extensions for a mobile desktop.

Development Environment

The cross-compilation environment of maemo is based on Scratchbox. Cross-compilation is a problematic issue in Linux systems, since build scripts typically utilize Autotools which have not been designed well for cross-compilation in mind. Thus, many Linux distributors solve the cross-compilation problem by avoiding it, and use dedicated hardware to run native compilations. This is a big limitation since sometimes native hardware build environment is difficult to arrange. And even if it were available builds run typically multiple times slower than in cross-compilation. Scratchbox solves this problem problem by totally isolating the target and host environments. Autotools based build scripts can be run on Scratchbox without modifications to build target platform binaries on a host system having a hardware platform other than the target.

Official maemo APIs are provided for the C language. Maemo also has C++ and Python bindings for its core APIs. Other unofficial bindings for other languages and environments exists.

Software Layers

In this chapter we shortly describe the software layers. The more detailed picture is given in the next chapter (The Software Decomposition View).

Operating System Layer and Bootup

The bootloader takes care of some hardware specific initializations and then loads the operating system kernel during the early stages of the boot up process. Maemo systems are based on Linux 2.6 operating system. At the last state of the kernel boot process the InitFS is mounted (a small JFFS2 file system image). It is used during the boot time as the root file system and in the normal device operation it is mounted into /mnt/initfs. The final root file system is on a JFFS2 image which is mounted after the InitFS boot scripts are done.

Applications on the InitFS are linked with uClibc, a minimal version of the C library in order to reduce space. The Device State Management Entity (dsme) is also located in the InitFS. The existance of the dsme daemon is vital so it is used to ping the hardware watchdog as well.

The Linux kernel is the central software component of the system. It provides the hardware abstraction layer for the system devices, memory management, process management, networking services including link and transport layer protocols like TCP/IP, file managment including file systems and various other services.

Parts of the kernel functionality can be implemented into dynamically loadable kernel modules. A kernel module can be loaded or removed during runtime. Kernel functionality like device drivers, network protocols, or file systems can be implemented into kernel modules.

The ARM/OMAP based Linux kernel on maemo devices implement hardware specific several device drivers and bus drivers on top of the core kernel's virtual services. The device drivers include USB, LCD, WLAN, Camera, and Audio, for instance. The bus drivers include Flash bus, SPI, I2C, and serial bus, for instance.

System Libraries

Maemo is based on the standard GNU C library. There exists the Standard C++ library as well. For networking there exists OpenSSL library that provides network security and libcurl that provides the HTTP access for applications.

For hardware abstraction, maemo provides HAL Hardware Abstraction Layer. It provides a shared library that has an API for device objects. A device object has properties and it is up to an actual device driver which properties it supports. HAL is thus capable of loading the right device driver when a new device is detected, creating and maintaining /dev files, tracking the status of devices and providing a means to uses each device.

System Services

The primary communication channel between applications is DBUS. DBUS also provides a channel for interaction between system and applications. DBUS is also used to invoke all the applications by sending messages.

The system provides an SQL database, SQLite 3, that can be used to store user application data. SQLite database is accessed through a library interface; there is no centralized server process to connect into.

Hildon Framework

The user interface is based on X Window System having Matchbox window manager. The application programming API on top of X is GTK+ widget toolkit with Hildon extensions. GTK+ is the UI framework of GNOME project as well. Other GNOME components have also been included in maemo, like GConf application configuration management, XML library, GnomeVFS, Evolution Data Server for address book and calendar management, GSF structured file streaming, and SVG (Scalable Vector Graphics). The multimedia framework is also the same, GStreamer based.

Hildon framework provides components on top of the GNOME components to support control panel, status bar, task navigator, and home applets. Hildon framework also provides backups / restore service, help framework, and an application installer.

Applications

The applications are build on top of the Hildon framework. Simple applications link just with Hildon libraries, GTK+, Glib, and libosso in order to use the graphical user interface elements. More complex applications use other services according to their needs, for example, they link with GStreamer for multimedia access and libcurl for HTTP access.

Software Decomposition View

Software Components

The main components of maemo are presented in the table below. Just click on any component to read more details. The component division does not map one to one on the actual package division since some abstraction has been added. In addition, the layers in the picture do not mean actual package dependencies from an upper layer to a lower layer although some correlation to the actual dependencies do exist (like none of the components below GTK+ depend on it).

The components marked with yellow color are provided as binary only in general (some subcomponents in them may be provided with source code though), others come with source code as well. Some specific applications, however, are provided with source code. Some maemo specific components are described in more detail below.

Maemo Connectivity Subsystem

The maemo Connectivity subsystem is implemented by using known Linux conventions. It resides in the user mode area of Linux and relies on Linux kernel through standard C libraries. Wireless LAN is the main channel to the Internet but dial-up connections through cellular networks are also supported. The only medium to the phone is Bluetooth. The Bluetooth software of maemo is based on BlueZ, which is known as the de-facto implementation of Bluetooth for Linux. D-Bus is used for internal application level message exchange.

Components of the maemo Connectivity Architecture include:

Maemo connectivity UI - User Interfaces parts of the connectivity. This includes Connection manager, Control panel applets and several different dialogs.

WLAN device driver - Device driver for Wireless LAN (IEEE 802.11g). Kernel driver is composed of two parts, a binary part (closed source) and an open source wrapper, which binds the binary to current Linux kernel.

Maemo System User Interface

System UI contains two parts. One is the System UI itself and the other one is System UI plugins.

System UI provides main application for system UI plugins including responsibility of plugin loading and unloading.

Embedded devices have special needs for text input. This framework provides the text input methods.

Hildon Home Applets

Home applets (also called as plugins) are small applications on the main window. They can provide online wether information, for instance, or a view to latest news titles.

Hildon Control Panel

Hildon control panel is the standardized place for put settings changeable by the end users for applications, servers etc. in the system.

Hildon Task Navigator

Hildon Task Navigator provides the menu for switching between applications. To make application visible in Hildon Task Navigator it needs a Desktop file for the application. This file contains all the essential information needed to show the application entry in the menu, like name, binary and D-BUS service name. Name of the file should be [application].desktop and location in filesystem “/usr/share/applications/hildon/”.

Hildon Status Bar

Status bar is a UI component that displays the status of various system tasks with a small icon image on the main window. The maemo status bar can contain user defined items as well. Normally there's places for two of these additional items. These two slots are used by usb connection indicator and alarm indicator, but can be used by any plugin. Although plugins can specify a priority the current version of status bar doesn't handle the plugin priorities, so only the two newest plugins are visible.

The maemo backup application saves and restores user data stored in ~/MyDocs (by default) and setting directories/files /etc/osso-af-init/gconf-dir (a link to GConf database /var/lib/gconf), /etc/osso-af-init/locale, and /etc/bluetooth/name. It can be configured to back up other locations and/or files as well by custom configuration files.

The backup application must not to be distrupted by other applications writing or reading during a backup or restore operation. For restore process, Backup therefore will, if the user approves, ask the application killer to close all application, and then wait until it has been done. For backing up, the backup_start and backup_finish D-BUS signals will be emitted on the session bus, which will indicate to applications that they should not write to disk.

Maemo Installer

Maemo installer is an application that is capable of managing application installations and upgrading. The architecture underneath is based on dpkg and apt.

Maemo Alarm Framework

The alarm framework provides mechanism to manage timed events. Timed event functionality is provided by the alarmd daemon. It makes possible for applications to get D-Bus messages or exec calls at certain times.

Packages included in the subsystem are:

libalarm

alarmd

Maemo Help Framework

The Help Framework is a centralized way to offer the user help services for your program. Maemo platform has inbuilt help system that handles all help documentation for the programs using the Help Framework. You only make use of the libraries that register your program to the Help Framework, and write the content of the actual help documentation. An ID tag will be given to the help file, which will be in XML format. This way you can control which help file will be loaded, when user asks for help, just by calling the right help content ID. When using the Help Framework, the help documentation for your program will also be available when using maemo Platform Help application.

Maemo Launcher

Maemo launcher launches all applications on the maemo platform. It is there to speed up application startup by sharing some of the initialization data of an application startup. Maemo Launcher is composed of two parts: (i) the maemo-invoker, which is executed by D-BUS daemon or scripts to start the given (application) service, and (ii) maemo-launcher, a server that has initialized most of the data used by the applications.

The maemo-invoker asks maemo-launcher to start the actual application. Use of maemo launcher requires that application is compiled as a shared library. There's a set of helper Debian package rules which make an application to “automatically” use maemo-invoker when given suitable build options. As a result, the application binary name is linked to maemo-invoker and application (library) binary name has .launch extension. By default the invoker will wait until the maemo-launcher tells it that the application has exited so that it can return the correct return value for the caller.

The maemo-launcher is a server process that has initialized most of the data used by the applications, such as Glib types, Gtk theme and some Gtk widget classes. When it's asked by maemo-invoker to start an application, instead of executing the application binary, it will dl-load that as a shared library, fork and call main(). With fork, the initialized data is handled as copy-on-write, i.e. shared until it's modified. If the application exits abnormally, maemo-launcher notifies Desktop so that Desktop can inform user about it.

Because prelinking doesn't work with dl-loaded libraries, maemo Launcher cannot speed up starting of applications where library linking has larger effect on the startup time than AF library initializations. It can still save memory though.

Sapwood

Sapwood provides a server and client library to accessing theme images. The server is responsible of loading the theme related images and distributing them to clients. Sapwood saves memory compared to Pixbuf engine which does not share the bitmaps between applications. Sapwood is also much faster because it tiles the 16-bit images using X server whereas pixbuf engine scale the 24/32-bit on the client side and then converts them to 16-bit for X server for blitting. This means that Sapwood is several times faster:

Bilinear scaling -> tiling = much faster

Scale+blit -> tile = 2x faster

24/32-bit -> 16-bit = 1.5/2x faster

24/32 to 16-bit conversion on blit -> doing it only first time = ~2x faster

LibOSSO is a shared library containing required and helpful services for maemo applications to integrate them better with the platform.

System Software

System Software subsystem provides system wide services to applications and users. The services include device state management (dsm), mode control (mce), battery management (bme) and few graphical user interface elements to manage the behaviour of the services.

More detailed description of the components:

Device State Management: Responsible for managing the states of the device including shutdown and startup. In addition, dsm is responsible for keeping the device running and operational. This is achieved by monitoring the status of critical processes such as D-Bus, X11 and Window Manager. Finally, dsm is responsible for tracking inactivity and based on that initiating power saving operations (turn off screen).

Mode Control: Provides interfaces for controlling of device modes, such as offline mode (disabling of Bluetooth and/or WLAN), and various system level user interfaces, such as device lock, touch screen and keypad lock, LEDs, etc.

The Power Management (PM) framework revolves around the concepts of dynamic tick, OS idle, clock framework and DVFS. PM framework can be divided into two independent mechanisms - OS idle and DVFS.

OS idle is based on the operating system scheduler. Whenever the scheduler has no tasks to perform it calls the idle function. The idle function can then choose to shutdown all or parts of the hardware and thus save power. The level of power savings dependes on the clock and voltage resources in use.

DVFS allows to scale down the SoC’s frequency and voltage at runtime to reduce leakage currents and hence save power. The decision to scale the frequency (and consequently voltage) of the ARM and DSP processors is based on the load on them.

OS-idle and DVFS are triggered independently of each other. DVFS is triggered based on increase or decrease of required processing power while OS-idle it triggered by the Linux scheduler.

Currently the suspend and resume functionality provided by Linux Driver Model is not used. Also, the kernel level power management does not get any guidance from the user space.

Clipboard

In maemo there are number of clipboard enhanchements to the X clipboard and Gtk+, in order to able to

Support retaining the clipboard data when applications that own the clipboard exit.

Be able to copy and paste rich text data between Gtk+ text views in different applications.

Provide a generally more pleasant user experience; make it easy for application developers to gray out "Paste" menu items when the clipboard data format is not supported by the application.

Compression

This subsystem provides various libraries and utilities for general purpose data compression and uncompression. The supported compression algorithms include the Lempel-Ziv (gzip) used in zip and PKZIP as well. Supported compression formats include:

ConIC provides an interface for manipulating and using Internet access points (IAPs) and IAP connections.

Certificate Manager

The maemo platform offers an API to deal with certificate manager storage and handling. This enables every piece of software to have access to all certificates, so that, for example, installing a new CA certificate takes immediate effect in all relevant programs (such as Web browser, e-mail, VPN and wireless connection). This saves effort and disk space.

The root file system thus contains all the components of the component decomposition table other than the lowest layer.

Essential Packages and the Delta to Standard Debian Systems

The core distribution is Debian based having tools like dpkg and apt for installation package management. Also sysvinit, base-files and base-passwd are included from the list of Debian Etch essential packages. A couple of differences to standard Debian exists, however. One is the replacement of Bash and coreutils with Busybox, an optimized command line tool set and shell for embedded devices. There is no bsdutils package as such but Busybox provides logger and renice utilities (script, wall and scriptreplay are missing). Diff has also been left out as well as e2fsprogs and ncurses packages. The size reduction just from the utilities and libraries is about 2.5MB and an additional 1.5MB from replacing Bash.

Secondly, there is no Perl in the system. It has been left out from the standard maemo environment to save space but can be installed separately by the user. In addition, note that there is no cron daemon. With Perl and Bash also removed the size reduction is about 6MB. The following table summarizes the the differences.
Package
Maemo
Debian
base-files
included
included
base-passwd
included
included
dpkg
included
included
sysvinit
included
included
awk
in Busybox
included
bash
in Busybox
included
coreutils
in Busybox
included
debianutils
in Busybox
included
findutils
in Busybox
included
grep
in Busybox
included
gzip
in Busybox
included
hostname
in Busybox
included
ifupdown
in Busybox
included
login
in Busybox
included
module-init-tools
in Busybox
included
mount
in Busybox
included
net-tools
in Busybox
included
procps
in Busybox
included
sed
in Busybox
included
tar
in Busybox
included
util-linux
in Busybox
included
vi
in Busybox
included
bsdutils
logger and renice in Busybox, script, wall, scriptreplay missing
included
diff
--
included
e2fsprogs
--
included
mktemp
in Busybox
included
ncurses-base
--
included
ncurses-bin
--
included
perl-base
--
included
sysvinit-utils
last, mesg, pidof in Busybox, lastb, killall5, sulogin missing
included
Also note that Busybox may not support all command line options of the standard tool even though the tool is included. Check out Busybox manual for more details.

Run Time View

Overview

User starts applications primarily from the Task Navigator, but they can be started also from the Status Bar (e.g. connection manager), from File Manager to view a file, or from other applications (e.g. for “Send as E-mail” functionality).

To conserve memory, only single instance of an application can be running at the same time. If application is already running, it will only receive a message about the new invocation, such as “open file 'foo'” and top itself. User can switch to another, already running application either by using the Task Navigator UI, or by closing the topmost application.

Because device doesn't have enough memory to run all the applications at the same time, system may kill an application in the background that has indicated itself to be killable. Applications exit when users closes them from the application UI, or when system requests that.

Components

Components involved in the application life cycle management and switching are following.

Task Navigator

Task Navigator (TN) is used to:

List all the device applications in the Others menu so that user can launch them

Launch applications. See the section on launching applications

To background kill applications that have set themselves as killable, when system indicates that it's in the low memory state.

List all the running and background killed applications. Latter appear to user as they were still running

Switch between already running applications or to a background-killed application. This is done either by:

requesting window manager to top the application window, or

sending the application a message requesting it to top a particular window view, or

re-starting the application in case it was background killed

D-BUS Session Bus

Each application in the device has a well-known name. E.g.: “Browser” or “Email”. The application name uniquely identifies the application. There’s a D-BUS service for each application, derived from the application name.

Applications are executed (activated) by the D-BUS session-bus daemon. If not running, an application is implicitly activated when a message with auto-activation flag is sent to the corresponding service. D-BUS gets the binary name to execute from the corresponding D-BUS .service file. The (activation) message may also contain parameters for the application, e.g. the name of a file to open in the application. D-Bus activation guarantees that at most one instance of the application is running at a time.

If the service doesn't register within given timeout, D-BUS assumes that the service (application) process startup failed and it will kill the started process.

Maemo Launcher

Maemo launcher exists to speed up application startup and to be able to share some of the data initialized at application startup. Maemo Launcher is composed of two parts: maemo-invoker: executed by D-BUS daemon or scripts to start the given (application) service. This asks maemo-launcher to start the actual application. Use of maemo launcher requires that application is compiled as a shared library. There's a set of helper Debian package rules which make an application to “automatically” use maemo-invoker when given suitable build options. As a result, the application binary name is linked to maemo-invoker and application (library) binary name has .launch extension. By default the invoker will wait until the maemo-launcher tells it that the application has exited so that it can return the correct return value for the caller.

maemo-launcher: a server that has initialized most of the data used by the applications, such as Glib types, Gtk theme and some Gtk widget classes. When it's asked by maemo-invoker to start an application, instead of executing the application binary, it will dl-load that as a shared library, fork and call main(). With fork, the initialized data is handled as copy-on-write, i.e. shared until it's modified. If the application exits abnormally, maemo-launcher notifies Desktop so that Desktop can inform user about it.

Because prelinking doesn't work with dl-loaded libraries, maemo Launcher cannot speed up starting of applications where library linking has larger effect on the startup time than AF library initializations. It can still save memory though.

Window Manager

Matchbox window manager takes care of handling the window switching and window stacking. See window management section for more information.

Application activation

User starts applications from the Task Navigator. Task Navigator starts the applications by sending a D-BUS message to the application service with the D-BUS auto-activation flag set.

Applications can also be started implicitly when other applications send them D-BUS messages, e.g. to open a mime-type that application has registered to the MIME database.

Places where different applications get the (application) D-BUS service names:

Task Navigator: Service name is specified in the application .desktop file along with the(localized) application name and its icon

File Manager and Browser: service name is retrieved from the gnome-vfs mime-type-handler application registry through libosso-mime library

Other applications use the service application API libraries. The libraries know which service the service application implements/registers to D-BUS

D-BUS daemon looks into application .service file to know how to execute the application before delivering the message. Applications launched by the D-BUS daemon will only have one instance of them running, because D-BUS does not allow the same service name to be registered by more than one process. Applications should not care whether the recipient of their message on D-BUS is running or not, they should just send all messages with the auto-activation flag to cause automatic activation of the recipient when it is not running.

Note that using the auto-activation flag is not always desirable, e.g. when asking the application to shut down; thus the application framework does not force using the flag. An activated application will automatically appear on the foreground.

Task Navigator supports also executing the application directly if the application D-BUS service name is missing from its .desktop file. This way the launched application does not need to know about D-BUS or Libosso at all, so any unmodified Open Source program that has a .desktop file can be launched this way. Single instance is not guaranteed for applications started like this.

Application can use maemo Launcher to speed up it's startup. Figure 2 shows how this happens in practice.

Passing Environment Variables

Application launched by the D-BUS daemon will inherit environment variables that were defined at the time when the D-BUS session bus was started. D-BUS does not provide a way to change the environment variables passed to an application to be activated.

Application launched by Task Navigator could inherit any environment variables if we implement such a feature to it. But when Task Navigator uses D-BUS to launch the application, the situation is the same as directly launching the application using D-BUS.

Application launched by the maemo-launcher will inherit environment variables that were defined at the time when the maemo-launcher was started. To be able to give the applications correct (pre-loaded) theme, maemo-launcher will listen on the theme changes.

Environment variable should not be used for dynamic configuration changes, since they require program restart and D-BUS does not support that.

Locale and language change is communicated through environment variables. As applications and their libraries also cache locale state (messages etc), changing this to use e.g. Gconf wouldn't help. Therefore changing the device locale or language requires restarting all applications and processes involved in application invocation.

Application termination

Applications exit when user closes them from the application UI, or when system requests that. System will request and force applications to exit for example when:

The device battery charge drops low enough

User switches off the device

User changes the device language

User resets the device back to factory settings

User tries close or to switch to an application that doesn't respond and user accepts system request about whether the application should be forcefully closed

In case a use-case gets system into low memory situation, system can request applications to background killed, see below. If there's not enough memory in the system to satisfy application request, that application requesting more memory will be out-of-memory (OOM) killed by the kernel.

State Saving and Background Killing

Application state saving is needed so that the application UI state and user data can be restored in the in case application crashes, or application is background killed. Applications are required to save their changed state when they go to background.

Background Killing

Application framework has a mechanism for shutting down GUI applications on the background to save memory so that other application can be run. This is called background killing.

Background killing is implemented by Task Navigator to (ideally) transparently close an application when the user does not see it and to restart the application when user needs it again. This is possible because applications are required to be able to save their user interface (UI) states and Task Navigator knows all running UI applications. Application is required to save its UI state when goes to background, i.e. behind some other application's window.

Unfortunately saving the UI state may not be feasible for the application in every situation (there's e.g. a download in progress), that is why the application notifies Task Navigator when it has saved the state and can be killed. Task Navigator will kill all the killable applications when system notifies that it's in low memory situation. When the application is started again, it is required to rebuild the UI according to the (possibly existing) saved state. Task Navigator won't try to (re-)start an application if there's not enough memory in the system for that.
Problems with background killing in maemo:

The killed application could be immediately below the top application in the window stack and in case the user closes the top application (from the application’s own menu), the user should see the application that was just closed, but won't, until it has restarted and initialized itself.

Currently Task Navigator checks whether a new application can be started by comparing the amount of system free memory with a build-time configured value. This might be less than a specific application would require or in some cases more than would be required. Application specific minimum required free memory value would be more optimal.

UI State Saving

The following picture describes a scenario where application A saves its state, exits, restarts and reads the saved state. The libosso library only creates the state file and provides the file descriptor to the application. Libosso will make sure that the real state file will not be updated until the state file write has completed and file closed. The application uses the standard POSIX file system API for writing and reading to the file descriptor.

If device is restarted, the UI states will be discarded, so that applications start from their default state. Each application with different version number will have it's own UI state file. This means that if application is updated (it's version number given in libosso initialization is changed), it will start from the default state.

Autosaving User data

Some applications are required to save unsaved user data periodically when on the foreground (top), so that as little as possible is lost on battery failure. Applications should register a libosso callback function for this operation and tell libosso when they have "dirty state" (user data has changed), libosso will then tell applications when they should do the autosave. (In current implementation this is just a timer in libosso, but reason for this API is that later on the saves can be synchronized with device power management.)

Note that applications should call "forced autosave" libosso function when they go to background (libosso doesn't know when this happens).

Window Management

There are several components participating in window management. X server does all the graphics and window handling operations. Matchbox window manager implements the window management policy, it takes care of:

Themed drawing of titlebars and dialog borders.

That dialogs being transient to an application window (or another dialog) are moved in the window stack together. For example when application is topped, it's dialogs are also topped.

When application switches to fullscreen mode, titlebar and panels (like Task Navigator and Statusbar) are hidden.

System dialogs and windows always keep above any application windows.

When input method opens, application window is resized and dialog is moved so that it doesn't overlap with the input method. If dialogs would go out of screen they are resized so that they are fully visible.

When window is opened, giving focus to new window and when a window is closed, giving focus to next window.

Third component of window management is Task Navigator. It keeps a list of all windows and views that applications have open from which user can switch to them. If application is closed through state saving and background killing, Task Navigator will still show it in this list so that it seems to user as the application were still running.

Application Views

In maemo applications implement views using HildonWindow widgets which each have their own X window which all belong to the same HildonProgram window group. In our UI style all dialogs are modal and earlier the dialog blocking an application could not have been raised above the window(s) that it was blocking. The HildonWindow supports standard window properties like window specific icons etc.

Application Topping

Application can top itself or Task Navigator can top the application. When an application is topped by the Task Navigator and it is already running, the topping is done by sending a standard X message.

When another application sends a message to the application requesting some functionality (e.g. File Manager tells image viewer to show a file), it is automatically started (but not yet topped) by the D-BUS daemon (if it is not already running and auto-activation is desired). When the application receives the message, it can raise its window if the operation requires user interaction.

Registering Windows to Task Navigator

For Task Navigator to be able to top application windows, it needs information that tells which window(s) belong to which application. This mapping is done with the application .desktop file StartupWMClass field.

When an application is launched by the D-BUS daemon, Task Navigator compares the WM_CLASS property of the opened application window to the StartupWMClass field in the application .desktop files to see for which application it belongs to. WM_CLASS window property is automatically set to the application binary name by Gtk. Application icons in the Task Navigator application launcher and switcher menus are also taken from the .desktop file.

If application WM_CLASS doesn't match StartupWMClass of any .desktop file, there will be no icon for the application in the Task Navigator application switcher and user cannot switch back to the application. This is a limitation of the current Task Navigator and hopefully fixed in later products.

Closing Application Windows

Application windows are in a stack. When you top an application, it comes on top of the stack. When window is closed, previously shown window is shown. Application window stack is separate from system (dialog) window stack.

System-UI Window Layer

All System-UI windows are on the prioritized system modal "dialogs" layer i.e. windows with the KEEP_ABOVE property. Matchbox window manager keeps them on top of all other system and application windows and dialogs.

0-N System-UI windows are visible at the same time.

The topmost (active) window always does pointer and keyboard grabs. Normal application menus do also these grabs, in OSSO they are required (modified) to close and release grabs when another window comes above them.

All of the System-UI windows are taken care of by the same process and it has a certain internal stacking order for them. I.e. same window comes always in the same position, but all of them might not be visible or even exist at the same time.

There's also a 1x1 window outside the screen which is always mapped to catch Gtk theme change messages.

Misbehaved Applications

The application framework assumes that applications are well behaved. However, in a few situation it checks that application has not jammed by sending a standard [EWMH] _NET_WM_PING message to it and expecting an answer. Gtk will automatically answer the ping in the Gtk event/main loop if application runs it.

This pinging is done by the Matchbox window manager when:

The application window close button is tapped i.e. user tries to close the application

Task Navigator asks it top an application window i.e. user tries to switch back to the application by selecting it from the Task Navigator application switcher. This is needed because window close button is not visible for fullscreen applications (in fullscreen mode user can use the Home key to switch between applications).

If the application doesn't answer timely, window manager informs Task Navigator and that will show user an dialog requesting whether the application should be terminated. If user accepts this, first a TERM and then KILL signal is sent to the application process (process ID is taken from the window _NET_WM_PID property) and the killing is logged. The dialog will go away automatically if application answers the ping while dialog is open.

If a maemo-launched application terminates abnormally, maemo-launcher will send a message to Desktop which will inform user about it. For more information on how applications could misbehave.

Major APIs

Major APIs are listed in the table bellow. APIs like the X APIs are not listed here since they are intended to be internal use only and not for application programmers.