Maemo is an open source development platform for Internet Tablets. It means the collection of software that is used to develop and test software for the Internet Tablet-class devices, the first of which was the Nokia 770. It was later followed by the Nokia N800 and the Nokia N810. In this material we will be referring to all of these devices as Internet Tablets. Maemo is a registered trademark of Nokia Corporation.
This version of the material covers maemo SDK version 4.x as well as Nokia N800 and Nokia N810 Internet Tablets running OS2008.
[ Nokia N800 ]
For a programmer, the Internet Tablets are really interesting as so much in them is based on free software and thus it's possible to use the same tools that are used in normal software development on other free and open source environments.
If you're coming from the Windows-world, or even the Symbian-world, this might be a new kind of encounter for you. All the tools, libraries and development processes that are used in maemo are equally used and applied in the desktop application arena, as well as for building server software. This is in part due to the GNU project (http://www.gnu.org/), which has implemented a lot of the tools infrastructure in a highly portable way. The main graphical interface libraries come from the GNOME project (http://www.gnome.org/), which is one of the most popular graphical environments used in Linux distributions.
By reusing existing portable and tested tools, we gain in an accelerated application development time. This also means that we can take the tool-set and apply it for writing software for embedded systems.
The devices are smaller than a laptop, larger than a PDA, and quite light-weight. Some of them (Nokia N810) have a small keyboard, and all of them have a stylus and a touch-sensitive screen. The stylus-driven GUI will cause some design challenges later on, since your software will need to be designed this in mind. There is also a possibility of using an on-screen keyboard with the stylus and this includes a hand-writing recognition and a predictive input system to aid the user. In all devices, there is a limited set of hardware buttons available for applications.
[ The Virtual Keyboard (VKB) ]
As a programmer, you will likely appreciate knowing a bit about what is hidden under the hood of the devices for which you program.
This is a short list of the most important components:
| 770 | N800 | N810 |
|---|---|---|
| an 800×480 pixel, 225 pixels-per-inch (PPI) wide-screen touch screen display with 16-bits per pixel color depth | ||
| Hardware buttons with a layout optimized for web surfing | ||
| Virtual Keyboard | Small slide-out keyboard (& VKB) | |
| Wi-Fi (802.11b/g) | ||
| external GPS via Bluetooth | Integrated GPS (external also supported) | |
| a 1500 mAh battery | ||
| 3.5 mm stereo audio out socket (works also as mic input on N800/N810) | ||
| built-in VGA resolution webcam | ||
| a USB 2.0 port (in target mode by default) | ||
| 64 MiB of RAM | 128 MiB of RAM | |
| 128 MiB flash memory with JFFS2 file system | 256 MiB flash memory with JFFS2 file system | |
| an RS-MMC memory card slot | Two memory card slots, SD, MicroSD, MiniSD, MMC, and RS-MMC (some types with extender). | One memory card slot, compatible with MiniSD and MicroSD (with extender). |
| Bluetooth 1.2 | Bluetooth 2.0 | |
| TI OMAP1720 multi-core processor with maximum clock frequency of 220 MHz which contains: | TI OMAP 2420 multi-core processor with maximum clock frequency of 400 MHz which contains: | |
The USB port normally acts as a USB-target, although with a proper kernel module the direction can be reversed so as the device can be the USB-host (initiator). The port is not capable of providing USB power so an external power feed would be necessary. This allows various usage-scenarios when the R&D mode is enabled on a device. The default version of Internet Tablet software runs in target mode only.
This material does not cover the hardware interfaces of the device itself, which is beyond the scope of this material.
Some noteworthy things about the hardware and software:
Please note that the above feature list holds for the "end user" version of the software that is shipped with Internet Tablets.
Below is a picture of the software "stack" for the maemo platform:
[ Software stack of maemo 4.0 ]
We'll start from the bottom layer and go upwards by covering the services:
[ Task navigator, Home and Status bar. Also shown are the icons (the GNU heads) of the hello-world-app package. ]
This is a short and simplified introduction to the X Window System. It is covered here because it is the underlying system by which graphics and user interaction is implemented in both the maemo platform and the Internet Tablets.
The X Window System is an architecture independent client/server system that allows multiple programs to interact with a user via a graphical (pixel-based) screen, keyboard and a pointing device (traditionally a mouse).
The program that wants to display something to the user, and read input from the user is called the X client. Each X client connects to one X server which will perform the requested graphics operations and will relay keyboard and pointer events back to the client.
When speaking about clients and servers, it's easy to make the mistake of reversing the meaning of client and server. It helps to think about the roles from the standpoint of the application, not the user. When the client starts, it will connect to some X server to create a window. A window is a rectangular area into which the client can draw. Note that the client can ask the server to position the window at some screen location, but normally doesn't. There is a special kind of client that will handle the placement of the windows of all other clients. This client is called the window manager. The window manager usually draws some graphical elements around each client's window, so that the user can more easily tell the boundaries between the windows. It also handles all HID-events in the window decoration areas, implements window minimizing, closing, etc. The HID-events that occur within the client area of the window are passed to the client.
There are a lot of different window managers, but most work in similar ways. The "Desktop" (whatever the word means inside a computer) is normally implemented by yet another client. And yes, the taskbar that you might see is yet another client. Even the screen saver is a separate client. In the real world there are some exceptions to the above arrangement, but having separate clients for all the elements is the most common case.
The protocol that clients use with the server is called X11. It is stream-based and bi-directional (for obvious reasons).
Clients can commonly connect to the server in two ways:
How does the client know where to connect? By using an environmental variable called DISPLAY. There are only a handful of applications that know how to implement the X11-protocol, because it's quite complicated to encode and decode. Normally clients will use a library called Xlib, which was developed for this purpose. Xlib also contains the logic to read the DISPLAY-variable and will get the address to connect to from the contents of the variable. It is also possible to tell the client to use a specific display via a command line parameter (--display=). The parameter will be processed internally by Xlib and override the environmental variable (if any).
The content of the DISPLAY-variable consists of two parts:
gethostbyname library call. In practice this is most often a DNS-name or an IP-address of the server, but depending on local NSS (Name Service Switch) be something else as well. This material will assume that DNS or IP will be used.So, for example: DISPLAY=remote.machine.com:0.0 would mean the first screen on the first X server running on remote.machine.com. When starting an X server, you normally can tell it which screen to create and control.
Wait a moment! What about the "similar to TCP but not quite" UNIX domain socket? Xlib will connect using a system specific file system path when the hostname-portion is empty. You can try it out on your Linux desktop like this: type echo $DISPLAY in a terminal emulator. Your graphical terminal emulator will connect to your X server knowing the DISPLAY-variable. It most probably is :0.0 unless you have a more complicated system (e.g., split dual-head).
To instruct an X client to connect to another X server, it's then necessary to modify the environmental variable: export DISPLAY=:2.0 for example. Then start your X client and it will at least try to connect to the X server specified. In the example above the server is running on the same system as the client (the hostname part is empty). Since the screen part is optional, you may also use export DISPLAY=:2 .
You might be wondering what all of this has to do with maemo, but you'll see in a short while when we install the environment and start testing the applications.
In the case that you skipped the intro, this is a good point to remind you that X11 is architecture independent. This means that applications running on Internet Tablets (ARM-binaries) can connect to an X server running on a x86/PC Linux (or even to an X server running on Apple OS X, Windows or other operating systems).
As a side note, the Internet Tablet has an X server as well. It runs as :0.0. It is a special version of an X server that requires less memory and has been configured to support most of the extensions used on the Linux desktop. The version on Internet Tablet is based on the Kdrive version of the X.Org X server (yes, so many versions). However, your Linux desktop is running a regular X.Org server.
Also note that by default most modern Linux distributions ship with the X server not listening for network connections. They will only accept local connections through the UNIX domain socket (/tmp/.X11-unix/X0 where 0 is server screen number).
For more information on X, please see the X.Org-project pages (http://www.x.org/) and http://www.rahul.net/kenton/xsites.framed.html. Also, ssh can be used to tunnel X11 connections securely over networks. Please see http://www.vanemery.com/Linux/XoverSSH/X-over-SSH2.html for examples.
We next take a look at the components making up a typical GUI application developed for maemo (starting from the bottom):
.zip, .rpm, .tar.gz, etc.) or a memory card. Modeled to follow POSIX-style file and directory operations. Basic operations are covered in this material.Whew, that was quite a list. As you can imagine, an introductory material like this cannot even try to cover all the possibilities or the API functions available in these libraries. We will try to do our best describing the bare minimum in order for you to start writing applications for maemo.
There are some caveats related to API changes between major GTK+ versions, which will be mentioned in the text, so do not go and copy-paste existing code blindly. Also this is a good place to remind you that most of the source code that you can find easily is covered by either the GPL or LGPL licenses. This material tries to stay away from legalese, but to put it bluntly, you cannot copy GPL-ed source code into your proprietary projects (i.e., closed source). This is against the license. GPL considers static linking as distribution (copying) too. Even linking dynamically from proprietary code against GPL-ed libraries might be interpreted as prohibited by the license!
Note that it is normally allowable to read and learn from GPL-ed source code. Indeed, unless you're copying line by line from existing code base, this can be an invaluable tool to learn how things are done in the "real world". This is quite the opposite when reading proprietary source code as there is a risk of learning something that the code owner will consider "intellectual property". If you then use this "knowledge" in a free or open source project, you risk polluting that project with unnecessary legalese.
As a side note, you might be interested to learn that almost all of the GNOME-libraries are released under the LGPL-license. This means that you can create proprietary software which will link into LGPL-libraries dynamically at runtime. If you however modify the LGPL-library, the modifications must be available in source form to the entities you distribute the binaries to under the original license (LGPL).
Low power consumption is one of main hardware design goals with mobile devices because of the limited electric charge in their power supplies. If the hardware is designed correctly, it may itself contain logic and rules to enter different power saving states. To enter these power saving states the hardware requires that there is no activity in the system, in other words, there is no task ready to be run by the OS kernel scheduling mechanism. Even if power saving functionality is implemented in the hardware, activating it might not always be possible. If the applications running on the hardware are "misbehaving", then the system will be active all of the time and this makes it impossible for the power saving features to be activated at hardware level. Some of these power saving features include: changing the clock frequency dynamically, supporting multiple operating voltages and switching integrated peripherals' sleep modes.
Different parts of the hardware will require different amounts of power to run. The following pie diagram is not based on any real measurements but roughly shows how power consumption is distributed between different subsystems in a device:
[ Diagram of power consumption in Mobile Devices ]
Keep the previous diagram in mind when you consider your application's "electricity needs". For example, in a GPS mapping application, the GUI interface is a graphical map with the position and other relevant information. If such display would keep the backlight active all the time, it would cause excessive power usage. In this case, it might be prudent to ask the user whether they really want to keep the backlight on, or provide a user-controllable button for switching the backlight on/off.
When designing for mobile devices, it's important that you (as the application designer) consider different approaches to problems. You should also consider system-wide power usage, i.e., how your application will change the power performance of the device. The above diagram might seem rather obvious, but it is often too tempting to start premature optimization of memory usage or code speed, and forget about power optimization. In mobile environments, all three are important.
maemo has its own website (at http://maemo.org), which includes:
There is also an IRC channel for developers (#maemo@FreeNode). You can find people related to Scratchbox and maemo hanging there lot of times. Scratchbox also has its own channel.
Note that everything you discuss on the IRC channel and mailing lists (as well as bugs you post using bugzilla) is public information. You might want to ask someone whether your working environment has a policy on using public resources before using them.
Using the previously presented software library stack is not the only possibility. The platform also includes SDL (Simple DirectMedia Layer) which is a library that was originally developed by Loki Entertainment, a company that specialized in creating Linux-versions of popular commercial games. It contains most of the code necessary to write games and implement low-level graphics. SDL is not covered by this material, but you can find the API (and other) documentation at http://www.libsdl.org/ .
If you like to work with APIs that are hard to understand, you can use the Xlib-interface and implement your interactive program directly with it (not recommended for the faint hearted).
Using either SDL or Xlib is not directly supported by the environment and will lead to applications which will not conform to the "look and feel" common to applications designed for maemo. Such problems should be avoided so that end-users do not get confused (they would expect an uniform interface for all the applications they use). You won't be able to utilize the virtual keyboard or handwriting recognition in your application either. For some fullscreen pointer driven games this might not be a big issue, but for "normal" GUI applications that the user will enter data and text, it is an issue.
It is also be possible to use the Python programming language (http://pymaemo.garage.maemo.org/) to write GUI programs (there are bindings for the Hildon toolkit as well) and there are community driven projects for using Ruby (http://maemo.rubyx.co.uk/ruby-maemo) and Vala (http://live.gnome.org/Vala) as well as others.
Copyright © 2007-2008 Nokia Corporation. All rights reserved.