mobileguide-0.5

8/3/2019 mobileguide-0.5

1/99

Ubuntu Mobile Guide 1 / 99

Ubuntu Mobile Guide


2/99

Ubuntu Mobile Guide

2 / 99

Copyright 2004, 2005, 2006 Canonical Ltd. and members of the Ubuntu Documentation Project

Credits and License

This document is maintained by the Ubuntu documentation team (https://wiki.ubuntu.com/DocumentationTeam). For a list of

contributors, see the contributors page

This document is made available under the Creative Commons ShareAlike 2.5 License (CC-BY-SA).

You are free to modify, extend, and improve the Ubuntu documentation source code under the terms of this license. All derivative

works must be released under this license.

This documentation is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied

warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE AS DESCRIBED IN THE DISCLAIMER.

A copy of the license is available here: Creative Commons ShareAlike License.
http://../common/C/contributors.xmlhttp://usr/share/ubuntu-docs/common/C/ccbysa.xmlhttp://usr/share/ubuntu-docs/common/C/ccbysa.xmlhttp://usr/share/ubuntu-docs/common/C/ccbysa.xmlhttp://../common/C/contributors.xml


3/99

Ubuntu Mobile Guide

3 / 99

COLLABORATORS

TITLE : REFERENCE :

Ubuntu Mobile Guide

ACTION NAME DATE SIGNATURE

WRITTEN BY October 15, 2007

REVISION HISTORY

NUMBER DATE DESCRIPTION NAME


4/99

Ubuntu Mobile Guide

4 / 99

Contents

1 Introduction 12

2 Developer Blueprints 13

2.1 Application Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Possible User Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Mobile User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Window Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5 Mobile Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6 Image Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.7 Mobile Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.8 Mobile Hardware Decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.9 Gnome Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.10 Screen Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.11 Mobile Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.12 Mobile Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.13 Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.14 Power Thermal Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.15 Power Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.16 Media Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.17 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.18 USB Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3 Setting up the Development Environment and Creating Images 51

3.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.2 Supported devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.3 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.5 Install and Run Image Creator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5.1 Instalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5.2 Creating an Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5.2.1 Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52


5/99


6/99

Ubuntu Mobile Guide

6 / 99

5 Anatomy of a Python Application in UME 69

5.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2 Application files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3 Application Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.4 Application auto-discovery via the .desktop file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.5 Executable file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.6 Main Python file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.7 Glade user interface file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.8 Icon file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.9 Sample make file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6 Using Glade and Python to create an Application for Ubuntu Mobile 73

6.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.3 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.4 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.5 Using Glade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.6 This Python programs structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.7 Creating the Hildon Program and Hildon Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.8 Importing the .glade file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.9 Reparenting to Hildon Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.10 Getting the menu and making it a Hildon Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.11 S ource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.11.1 main.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.11.2 Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7 Porting Python Applications to Ubuntu Mobile 79

7.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.2 Assumed Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.3 Get the Source Code and try it out on UME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797.4 Hildonize Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.5 Hildonize Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8 Porting C Applications to Ubuntu Mobile 85

8.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.2 Assumed Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.4 Get the source and try to compile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.5 Hildonizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

8.5.1 Now on to the menu functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89


7/99

Ubuntu Mobile Guide

7 / 99

9 Application Development for UME - An Example 91

9.1 Showing the User Relevant Information Based on their Location . . . . . . . . . . . . . . . . . . . . . . . . . . 91

9.1.1 Flash UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

9.1.2 The GeoClue backend. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

10 Theming and Customization of UME 98

10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

11 API References 99

11.1 D-Bus API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

11.2 GTK API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

11.3 Hildon API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

11.4 Gnome Developer Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99


8/99

Ubuntu Mobile Guide

8 / 99

List of Figures

2.1 Hildon Desktop Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Mobile Internet Device UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Mobile Internet Device UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.5 Project Builder GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.6 Overview of Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.7 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.8 GNOME Mobile components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.9 Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.10 Frequency Optimised Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.11 Mobile Wireframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.12 Thermal Control Software Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.13 Power Policy Management Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.14 API Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.3 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.4 Functional Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.5 Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.6 Default HTML UI with User Selected background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.1 gPodder on Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.2 gPodder UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.3 gPodder UME Hildon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8.1 Liferea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8.2 Liferea Hildonized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90


9/99

Ubuntu Mobile Guide

9 / 99

List of Tables

2.1 Energy Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2 Power Events Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42


10/99

Ubuntu Mobile Guide

10 / 99

About This Guide

Conventions

The following notes will be used throughout the book:

Note

A note presents interesting, sometimes technical, pieces of information related to the surrounding discussion.

Tip

A tip offers advice or an easier way of doing something.

Caution

A caution alerts the reader to potential problems and helps avoid them.

Warning

A warning advises the reader of a hazard that may arise in a given scenario.

Cross-reference conventions for print will be displayed as follows:

Links to other documents or websites will look like this.

Note

PDF, HTML, and XHTML versions of this document will use hyperlinks to handle cross-referencing.

Type conventions will be displayed as follows:

File names or paths to directories will be shown in monospace.

Commands that you type at a Terminal command prompt will be shown as:

command to type

Options that you click, select, or choose in a user interface will look like this.
http://www.ubuntu.com/http://www.ubuntu.com/http://www.ubuntu.com/


11/99

Ubuntu Mobile Guide

11 / 99

Menu selections, mouse actions, and keyboard short-cuts:

A sequence of menu selections will be displayed as follows: File Open

Mouse actions shall assume a right-handed mouse configuration. The terms click and double-click refer to using the left

mouse button. The term right-click refers to using the right mouse button. The term middle-click refers to using the middlemouse button, pressing down on the scroll wheel, or pressing both the left and right buttons simultaneously, based on the design

of your mouse.

Keyboard shortcut combinations will be displayed as follows: Ctrl-N .Where the conventions for Control, Shift, and Alter-

nate keys will be Ctrl, Shift, and Alt, respectively, and shall mean the first key is to be held down while pressing the second

key.

Contributing and Feedback

This book is developed by the Ubuntu Documentation Team. You can contribute to this document by sending ideas or comments

to the Ubuntu Documentation Team mailing list. Information about the team, its mailing lists, projects, etc. can be found on theUbuntu Documentation Team Website.

If you see a problem with this document, or would like to make a suggestion, you can simply file a bug report at the Ubuntu

Bugtracker. Your help is vital to the success of our documentation!

Many thanks,

-Your Ubuntu Documentation Team
https://wiki.ubuntu.com/DocumentationTeamhttps://wiki.ubuntu.com/DocumentationTeamhttps://wiki.ubuntu.com/DocumentationTeamhttps://wiki.ubuntu.com/DocumentationTeamhttps://launchpad.net/products/ubuntu-doc/+bugshttps://launchpad.net/products/ubuntu-doc/+bugshttps://launchpad.net/products/ubuntu-doc/+bugshttps://launchpad.net/products/ubuntu-doc/+bugshttps://wiki.ubuntu.com/DocumentationTeamhttps://wiki.ubuntu.com/DocumentationTeam


12/99

Ubuntu Mobile Guide

12 / 99

Chapter 1

Introduction

Welcome to the Ubuntu Mobile Guide

It contains information on how to use and how to develop software for the Ubuntu Mobile Edition

The Ubuntu Mobile and Embedded (UME) project aims to derive an operating system for mobile internet devices using Ubuntu

as a base. UME will extend Ubuntu by providing an infrastructure for mobile development, with all of the necessary components

integrated into the Ubuntu package archive, ready to install and run, or to tailor for custom mobile applications.

This guide assumes you have a basic understanding of your Ubuntu system. If you need detailed help installing Ubuntu, refer to

the Ubuntu Installation Guide.

The Mobile Teams area on Launchpad ishere
https://launchpad.net/~ubuntu-mobilehttps://launchpad.net/~ubuntu-mobile


13/99

Ubuntu Mobile Guide

13 / 99

Chapter 2

Developer Blueprints

Blueprints followed by Ubuntu Mobile developers during the creation of Ubuntu Mobile 7.10 Gutsy Edition. They provide an

insight into the thoughts and challenges they faced and are provided here as a historical record. Please consult the other chaptersin this manual for up-to-date instructions on any of the techniques they describe

2.1 Application Framework

Our major goal is to make it easy for distributions to package Hildon Desktop so that developers can have a quick-to-setup

environment for the development of plugins which do not need to be built against ARM such as Python plugins

Ubuntu Mobile and Embedded (UME) uses the Hildon Application Framework found in the Maemo project as the application

framework for the UME project. Mobile internet devices and tablets for which this distribution is targeted need an application

framework that can provide a way to create applications with a very consistent look and feel and be prepared to run and interface

nicely using restricted resources found on small devices like small resolution, little CPU power and storage. In addition, applica-

tions should be designed for touchscreen use, finger-friendly navigation, gestures, etc. Thus a specific UI framework, preparedfor this kind of demand is necessary.

Figure 2.1: Hildon Desktop Architecture


14/99

Ubuntu Mobile Guide

14 / 99

The Hildon Application Framework is one of a few existing frameworks designed for small devices and is a good candidate for

tablet use. It has strong support from Nokia and has been separated from Maemo to become part of GNOME Mobile. This has

allowed the Ubuntu community and others to contribute in a way that benefits all users.

This is the step-by-step procedure to have the Hildon Desktop that will be used in the Ubuntu Mobile and Embedded project.

Warning: Having the mobile system running in a normal Gutsy installation is likely to cause problems, especially in this earlystage of development therefore, its safer to have a chroot environment, which is what is described below.

Prepare a gutsy chroot in ${DIR}:

$ sudo debootstrap --arch i386 gutsy ${DIR} http://archive.ubuntu.com/ubuntu

$ sudo mount --bind /tmp ${DIR}/tmp

$ sudo mount -t proc none ${DIR}/proc

$ sudo mount --bind /sys ${DIR}/sys

Everything should be ready, so:

$ sudo chroot ${DIR}

The meta-package ubuntu-mobile provides all the necessary packages and its dependencies so, inside the chroot:

Add the universe repository to /etc/apt/sources.list:

deb http://gb.archive.ubuntu.com/ubuntu/ gutsy main restricted universe

Update the repositories and install ubuntu-mobile:

$ sudo apt-get install ubuntu-mobile

Those are packages that are likely to be used when developing applications using the environment above so you can have the

hildon desktop shown in your normal desktop.

xserver-xephyr

Create a normal user inside the chroot

sudo adduser ume

Prepare the script that the user just created will use to start hildon desktop.

#!/bin/bash

PREFIX=/usr

THEME=${PREFIX}/share/themes/plankton

export DISPLAY=:1

export GTK2_RC_FILES=${THEME}/gtk-2.0/gtkrc:${THEME}/gtk-2.0/gtkrc.

maemo_af_desktop

export LANG=en_GB.UTF-8

export LC_ALL=en_GB.UTF-8

export LANGUAGE=en_GB.UTF-8

/usr/lib/libgconf2-4/gconfd-2 &

${PREFIX}/bin/matchbox-window-manager -display ${DISPLAY} \

-theme ${THEME}/matchbox/theme.xml \

-use_titlebar yes \

-use_desktop_mode plain \

-use_lowlight no \

-use_cursor yes \


15/99

Ubuntu Mobile Guide

15 / 99

-use_super_modal yes &

${PREFIX}/lib/sapwood/sapwood-server &

exec ${PREFIX}/bin/hildon-desktop

Edit /etc/hildon-desktop/desktop.conf and remove or comment out the [Statusbar] session if necessary.

Enter the chroot start dbus

/etc/init.d/dbus restart

and su - to the user created above. Outside the chroot execute Xephyr like this:

Xephyr :1 -host-cursor -screen 800x480x16 -dpi 96 -ac

Execute the hildon-desktop script as the user you created above.

2.2 Possible User Applications

For the browser, Firefox will be used. There is already efforts to reduce its footprint and currently we are running an internal

version. If we need to fit the browser into a very small profile machine a possible alternative is Opera. In a operational level, both

are equivalent and can carry the same plugins.

The Maemo project just released a new browser, based on the gekko engine which is fully integrated into the hildon environment.

However we need a full xul-based solution so we are doing our own work on our own Firefox Embedded browser with:

Adobe Flash Player 9

Adobe PDF Reader

Java Runtime Environment(JRE)

For the Media player. Currently its being considered Helix. Possible option: mplayerThe player going to support both helix

and gstreamer simultaneously

For the Dictionary: Stardict seems to be the best option so far:

Small

Fast

Flexible

Bidirectional

Lots of languages available.

The interface needs work for usability and to better fit into Hildon.

For E-mail: The specification asks for Thunderbird which is a great email application but I think that a better alternative is

Clawswhich is a improved version of Sylpheed.

Lightweight

Fairly complete

Its already packed for Maemo so its easy for us to integrate.
http://www.mozilla.com/en-US/firefox/http://www.opera.com/http://www.opera.com/http://browser.garage.maemo.org/http://browser.garage.maemo.org/http://uk.real.com/player/http://uk.real.com/player/http://www.mplayerhq.hu/design7/news.htmlhttp://stardict.sourceforge.net/http://www.claws-mail.org/http://sylpheed.sraoss.jp/en/http://sylpheed.sraoss.jp/en/http://sylpheed.sraoss.jp/en/http://www.claws-mail.org/http://stardict.sourceforge.net/http://www.mplayerhq.hu/design7/news.htmlhttp://uk.real.com/player/http://browser.garage.maemo.org/http://www.opera.com/http://www.mozilla.com/en-US/firefox/


16/99

Ubuntu Mobile Guide

16 / 99

Theres a lot of plugins that we already have packaged like

news feed

baesian filter

spamassassin

acpi notifier (to blink a led if an email arrives, for instance)

smime

clamav

Disadvantages

None that I can see at this time.

Recently we were pointed to a new email client called Modest which will become (but, as far as I can tell, theres no official

position on that) the new email application for Maemo.

Advantages

It was created for Maemo so should be fairly easy for us to integrate.

Its still under heavy development;

It was created to be very light, adequate to a more limited hardware platform;

It Doesnt have all the possibilities as with Thunderbird or Claws and I understand that it will never have as its not the project

target.

For the Media Player

It is to be provided by Intel. It will use a simple frontend that will talk with Helix and gstreamer working as backends.

For the Camera

There are video capture applications (like xawtv, camE), programs that can read, record and process V4L devices like mplayer

and videolan which can also be used to process the stream in realtime using filters and programs like EffecTV, GePhexand

snapshot applications like Camorama. I couldnt find a single application that could do what we want, so I think that we could

use something like Camorama as base and add continous video processing. Maemo uses gstreamer as the backend and their

camera applications (which is closed) talks to it.

Possible applications: many (xawtv, camE, Camorama, mplayer, videolan).

There is one application being developed for the Google Summer of Code called Cheese that could be very handy. A Launchpad

project was created and the latest version available (0.13) was pushed.

It can capture video streams and stills.

Have a plugin system that can be used, and already is, to apply effects.

Uses gstreamer as the backend.

Its written in GTK.

Its far from complete.

It has severe bugs in interface with v4l2 and does not work at all with V4l.

As a matter of fact, so far I wasnt able to make it work with 3 different cameras.
http://modest.garage.maemo.org/http://docbook.wikiwikiweb.de/GePhexhttp://live.gnome.org/Cheesehttp://live.gnome.org/Cheesehttp://docbook.wikiwikiweb.de/GePhexhttp://modest.garage.maemo.org/


17/99

Ubuntu Mobile Guide

17 / 99

Ebook reader

Theres one FOSS champion: fbreader which is the one used by Maemo.

It can read a several formats like:

fb2 e-book format (style attributes are not supported yet).

HTML format (tables are not supported).

CHM format (tables are not supported).

plucker format (embedded images are supported, tables are not supported).

Palmdoc (aportis doc).

zTxt (Weasel format).

TCR (psion text) format.

RTF format (stylesheets and tables are not supported).

OEB format (css and tables are not supported).

OpenReader format (css and tables are not supported). Non-DRMed mobipocket format (tables are not supported).

Plain text format.

Disadvantages

Cant read DRMed books which can be a problem to commercial applications.

MikhailSobolev: DRM formats are mostly proprietary and their specifications are usually very well closed

A proprietary one, Mobipocket, seems to be an interesting option. They have a closed java lib that needs an UI. Thats the way

its used on the PepperPad.

It can handle DRMed ebooks.

Theres a limited number of formats supported. Currently only OpenEBook (OEB) besides itself.

Only for CHM there is alternatives like xchm and kchmviewer. Not very useful anyway. Theres others like dotReader but mostly

based on its own format or use Palmdoc/plucker only.

For IM

Pidgin (formerly known as Gaim) covers the specification out of the box with one exception, the Myspace IM protocol. There is

a plugin in the works, still alpha quality but it is already able to:

Send and receive instant messages

Buddy list support (basic support only)

Look up user information (in Get Info and tooltip text)

(Some) formatting of incoming instant messages

For Video Conferencing

Ekiga is the preferred application in the specification.

It covers the specification already.

Its a gnome application, so should not be difficult to integrate. Supports STUN.
http://docbook.wikiwikiweb.de/OpenReaderhttp://docbook.wikiwikiweb.de/MikhailSobolevhttp://docbook.wikiwikiweb.de/MikhailSobolevhttp://docbook.wikiwikiweb.de/PepperPadhttp://docbook.wikiwikiweb.de/PepperPadhttp://pidgin.im/pidgin/home/http://developer.pidgin.im/wiki/MySpaceIMhttp://ekiga.org/http://ekiga.org/http://developer.pidgin.im/wiki/MySpaceIMhttp://pidgin.im/pidgin/home/http://docbook.wikiwikiweb.de/PepperPadhttp://docbook.wikiwikiweb.de/MikhailSobolevhttp://docbook.wikiwikiweb.de/OpenReader


18/99

Ubuntu Mobile Guide

18 / 99

Its know to be problematic sometimes.

wengophone

A current option for Ekiga is wengophone

It can also work also as a IM client.

Using the Wengo service, calls to landlines and cellphones can be done.

Interface is based on Qt.

For an Office document viewer

Excluding PDF that can be read by Evince for instance, there is no FOSS software available to this kind of task but some very old

filters or format converters that only could be used with very old Microsoft formats. At this moment I can foresee 2 possibilities

related to FOSS software.

Include the appropriate filters into evince

Evince would become an universal viewer of sorts, handling all the viewing necessities in one place.

Disadvantage

It would be quite some work to integrate, say, the Abiword filters into it.

Modify the Office package of choice to have a simplified, read only mode, therefore using the same application for view and edit

files

Advantage

I guess that would be an easier task than modify Evince.

Disadvantage

Its inconvenient to load the office application just to view a file.

TextMaker Viewer

There will be a commercial product called TextMaker Viewer that fits very nicely but it does not exists yet and looks like to be

based on Qt.

For Casual Games

The specification asks for more action-packed games. Some suggestions, depending on the profile:

All-time favorites

Pingus

SuperTuxCart

SuperTux

Tux Racer

Frozen Bubble

Card games

PySol

Educational Games
http://www.openwengo.org/http://www.officeviewers.com/http://pingus.seul.org/welcome.htmlhttp://supertuxkart.berlios.de/http://supertux.lethargik.org/screenshots.htmlhttp://tuxracer.sourceforge.net/http://www.frozen-bubble.org/http://www.pysol.org/http://www.pysol.org/http://www.frozen-bubble.org/http://tuxracer.sourceforge.net/http://supertux.lethargik.org/screenshots.htmlhttp://supertuxkart.berlios.de/http://pingus.seul.org/welcome.htmlhttp://www.officeviewers.com/http://www.openwengo.org/


19/99

Ubuntu Mobile Guide

19 / 99

GCompris

If the machine can handle

Open Arena

Thunder&Lightning

Emulator

ScummVM

There is a huge selection available. It is just a matter of choosing.

RSS reader

Theres plenty of them available. The more suitable ones for our needs are Liferea and Straw. Both are quite equivalent but

Liferea is starting to make incursions to integrate with blogs which is an interesting feature. A second option is to use the one

integrated into the email reader. Both Thunderbird and Claws suggested above can do it.

For the Clock

This item is just a matter of choosing what gadget would fit best into the current home applet environment as the requirements

are quite common except for the fact that it requires the clock to run full screen but this should not be difficult to achieve. The

original Maemos panel clock or this clock applet can do that. Another option is GPEs clockthat is be an interesting option if

the GPE PIM described below is chosen.

For PIM

The GPEcan provide all the PIM needs easily. Some of the projects we can make use are:

Contacts

Calendar

Sketchbook

Voice Recorder

Today

Todo List

Time Tracker

Another option is Pimlico

For a Remote desktop client

Currently, we have tsclient which is a wrapper that actually runs rdesktop and vncviewer on demand. This covers the specification

with the exception of the listed functions:

Scaling an panning: needs to be implemented on the clients but, despite not being in upstream, this has been done before.

Stylus to Mouse click conversion is a matter of choosing input methods. There is no consensus around this yet and some

additional work might be necessary to give to the user a better visual feedback.

Other suggestions - TBD

Simple image manipulation

Should this be integrated with the media player?

Offline blogging client
http://www.gcompris.net/http://openarena.ws/http://tnlgame.net/http://www.scummvm.org/http://liferea.sourceforge.net/http://www.gnome.org/projects/straw/http://www.gnome.org/projects/straw/http://www.home.unix-ag.org/simon/files/n770/http://gpe.linuxtogo.org/projects/gpe-clock.shtmlhttp://gpe.linuxtogo.org/http://gpe.linuxtogo.org/projects/GPE-Contacts.shtmlhttp://gpe.linuxtogo.org/projects/GPE-calendar.shtmlhttp://gpe.linuxtogo.org/projects/gpe-sketchbook.shtmlhttp://gpe.linuxtogo.org/projects/GPE-soundbite.shtmlhttp://gpe.linuxtogo.org/projects/GPE-today.shtmlhttp://gpe.linuxtogo.org/projects/GPE-todo.shtmlhttp://gpe.linuxtogo.org/projects/gpe-timesheet.shtmlhttp://pimlico-project.org/http://freshmeat.net/projects/tsclient/http://www.rdesktop.org/http://www.rdesktop.org/http://freshmeat.net/projects/tsclient/http://pimlico-project.org/http://gpe.linuxtogo.org/projects/gpe-timesheet.shtmlhttp://gpe.linuxtogo.org/projects/GPE-todo.shtmlhttp://gpe.linuxtogo.org/projects/GPE-today.shtmlhttp://gpe.linuxtogo.org/projects/GPE-soundbite.shtmlhttp://gpe.linuxtogo.org/projects/gpe-sketchbook.shtmlhttp://gpe.linuxtogo.org/projects/GPE-calendar.shtmlhttp://gpe.linuxtogo.org/projects/GPE-Contacts.shtmlhttp://gpe.linuxtogo.org/http://gpe.linuxtogo.org/projects/gpe-clock.shtmlhttp://www.home.unix-ag.org/simon/files/n770/http://www.gnome.org/projects/straw/http://liferea.sourceforge.net/http://www.scummvm.org/http://tnlgame.net/http://openarena.ws/http://www.gcompris.net/


20/99

Ubuntu Mobile Guide

20 / 99

Simple html-capable wysiwyg editor and posting tool (ftp and common blogging APIs)

Voip client

Should be the same used for video conference?

Ekiga

Twinkle

OpenWengo

GPS software / Navigation software

GeoClue seems to be a good starting point and there is a Maemo port already.

Quick voice/audio recorder/audio notetaker

[...]

Image posting client (flickr/windows image posting wizard)

[...]

Packaging status

fbreader - pushed.

Cheese - pushed.

2.3 Mobile User Interface

Given the similarities in function and system characteristics to Nokia N-level hand-held devices, Nokias Hildon Application

Framework was selected as the underlying application/UI framework. The UME user interface will look markedly different and

be designed with user and OEM customization in mind.

Figure 2.2: Mobile Internet Device UI

System Characteristics

Low-power, hand-held mobile device
http://docbook.wikiwikiweb.de/OpenWengohttp://www.freedesktop.org/wiki/Software/GeoCluehttp://maemo.org/news/community/view/445e8586dc43867ee22def2915ee04cb.htmlhttp://maemo.org/news/community/view/445e8586dc43867ee22def2915ee04cb.htmlhttp://www.freedesktop.org/wiki/Software/GeoCluehttp://docbook.wikiwikiweb.de/OpenWengo


21/99

Ubuntu Mobile Guide

21 / 99

Screen dimension: 4.5" to 7"

Screen resolution: 800x480 up to 1024x600 (expected)

@512MB SSD, @512MB RAM (depending on model)

Limited or unknown hardware controls (UI needs to be able to do it all)

Mobile devices are not general purpose desktops. Generally they will have fewer applications than a desktop (~20 instead of

100s). It is assumed that the primary applications would be:

Browser

Multimedia apps (music, movie, photo)

Chat

Email

Camera

Location/GPS

Games

Configuration applets

Design

The core components are those found in GNOME Mobile, including GTK, matchbox window manger, and the Hildon Application

Framework. The UME Home Screen consists of one or more panels containing panel widgets/applets, and a large open area

containing home widgets/applets. The panel at the top is called the "Marquee". It is present when applications are running and

contains the application menu applet and close application applet. The number of panel and home widgets is restrained by space

only. It will be possible to configure the order and location of widgets. The Maemo UI also has these elements. Below is animage showing these pieces:


22/99

Ubuntu Mobile Guide

22 / 99

Figure 2.3: Interface

Mobile Internet Device UI

Figure 2.4: Mobile Internet Device UI

Hide the task navigator (a panel). (/etc/hildon-desktop/desktop.conf file change)

Create a new panel and place it at the top. (/etc/hildon-desktop/desktop.conf file change)

Add new plugins to our top panel (application menu and statusbar)


23/99


24/99

Ubuntu Mobile Guide

24 / 99

Utilities for creating live USB images of target file-systems for easy testing of multiple target file-systems

Developer uses project-builder to start a new project

Here we assume that:

The project is configured to work with a mccaslin type of device

The project is given a name myproject for future reference

The project is given a description of "My Samsung Q1 Ultra project"

The project creates a complete buildroot in /usr/src/myproject

$ sudo project-builder -c create-project \

--platform-name mccaslin \

--project-name "myproject" \

--project-path "/usr/src/myproject" \

--project-description "My Samsung Q1 Ultra project"

Developer uses project-builder to create a new target filesystem

Developer creates a new initial target device filesystem:

Since a project can create multiple target filesystems, the target is named target1

The new target filesystem is rooted at /usr/src/myproject/targets/target1/fs

$ sudo project-builder -c create-target \

--project-name "myproject" \

--target-name "target1"

Developer installs the Ubuntu-Mobile default set of packages for a full UI

Developer installs the "full-mobile-stack" functional set (fset)

The "full-mobile-stack" is a meta fset that depends on the Core, Infrastructure, GNOME-Mobile, Mobile-Applications, and

Power-Management fsets

After installing this fset, the target filesystem has enough functionality such that once installed on the target device, the device

can boot to the ubuntu-mobile installation and automatically startup into the hildon desktop with the standard set of ubuntu-

mobile applications

$ sudo project-builder -c install-fset \

--project-name myproject \

--target-name target1 \--fset-name "full-mobile-stack"

Developer tweaks the target filesystem as desired

The developer has the choice of building new mobile software from the project buildroot (which comes with the basic ubuntu-

mobile development packages installed), or building from their Gutsy host

The software will then need to be installed in the target filesystem. If building from the buildroot, then the target filesystem is

located at /targets/target1/fs, and if building from a Gutsy host, then the target filesystem is located at /usr/src/myproject/tar-

gets/target1/fs

Developer builds test the target filesystem on host system

Developer installs the Xephyr server in their workstation and starts a new Xephyr window


25/99

Ubuntu Mobile Guide

25 / 99

The "full-mobile-stack" is a meta fset that depends on the Core, Infrastructure, GNOME-Mobile, Mobile-Applications, and

Power-Management fsets

$ sudo apt-get install xserver-xephyr

$ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac &

Developer uses project-builder to chroot inside the target filesystem

Bind mounting /proc, /sys/, and /tmp

Copying over host network configuration files

Starting target daemons like dbus

Creating a fresh environment such that applications are not broke with host specific settings

$ sudo project-builder -c chroot-target \

--project-name myproject \

--target-name target1Password: XXXXX

#

Developer launches the hildon-desktop

# start-hildon-desktop &

Developer Creates an Installation Image

Project-builder provides several mechanisms for installing the new target filesystem on the device, including:

USB Install (boot a USB key that installs the target filesystem on the device)

Live USB (boot a working live image off a USB key)

Live RW USB (boot a working live image off a USB key that persist changes to the key)

ISO Install (user boots off a USB CD that installs the target filesystem on the device)

Live ISO (boot a working live image off a CD)

For this usage case, the developer creates an "Install USB" image and then writes the image to a USB key that shows up as

/dev/sdb on the developers workstation

$ sudo project-builder -c create-install-usb \--project-name myproject \

--target-name target1 \

--image-name live-usb.img

$ sudo dd if=/usr/src/myproject/targets/target1/image/live-usb.img of=/dev/sdb

Developer Installs the target filesystem on the device

Developer plugs in the USB key to the device and then boots device and enters the BIOS configuration and configures the boot

options to boot off a USB key

The device boots, automatically installs the target filesystem, and then shutdown

The developer unplugs the USB key and boots the device to see the running ubuntu-mobile stack


26/99

Ubuntu Mobile Guide

26 / 99

Build system generates an image for a given device

The build system uses the project-builder command line capabilities to create target images

# Inside the build script....

# $PLATFORM is the name of the platform

# $BUILDROOT is the build working directory# $DEST is the directory to place the target image

# Delete any existing build project

project-builder -c delete-project --project-name build 2> /dev/null || true

# Kick off a clean project

project-builder -c create-project \

--platform-name $PLATFORM \

--project-name build \

--project-path $BUILDROOT \

--project-description "Build system"

# Install a new target in the project

project-builder -c create-install-usb \


--target-name buildtarget \

--image-name install.img

# Install the standard mobile stack in the target

project-builder -c install-fset \


--target-name buildtarget \

--fset-name "full-mobile-stack"

# generate the an install USB image

project-builder -c create-install-usb \

--project-name build \--target-name buildtarget \

--image-name install.img

mv $BUILDROOT/targets/buildtarget/image/live-usb.img $DEST

Implementation

The project-builder tool can be used as either a command line tool, or as a GUI if no command line arguments are provided. For

a list of available command line arguments, use the --help argument:

$ project-builder --help

Usage: project-builder [options]

Options:-c CMD, --command=CMD

Where CMD is one of: chroot-project, chroot-target,

create-install-iso, create-install-usb, create-live-

iso, create-live-usb, create-project, create-target,

delete-project, delete-target, install-fset, list-

fsets, list-platforms, list-projects, list-targets,

update-project, or update-target

--platform-name=PLATFORM_NAME

Platform name

--project-name=PROJECT_NAME

Project name

--project-description=PROJECT_DESC

Project description

--project-path=PROJECT_PATH

Project path


27/99

Ubuntu Mobile Guide

27 / 99

-t TARGET_NAME, --target-name=TARGET_NAME

Target name

--fset-name=FSET_NAME

Feature set identifier

--image-name=IMAGE_NAME

Name to use for target image file-q, --quiet dont print status messages to stdout

-d, --enable-debug Enable additional debug package while installing fsets

-h, --help show this help message and exit

Examples:

project-builder --command=create-project \

--platform-name=mccaslin \

--project-name=MyProject \

--project-desc=Example project \

--project-path=/usr/src/projects/myproject

project-builder --command=delete-project \

--project-name=MyOtherProject

project-builder --command=create-target \


--target-name=MyTarget

project-builder --command=delete-target \


--target-name=MyOtherTarget

project-builder --command=install-fset \

--platform-name=mccaslin \


--target-name=MyTarget \

--fset=Core \

project-builder --command=chroot-project \


project-builder --command=chroot-target \

--project-name=MyProject \--target-name=MyTarget \

project-builder --command=update-target \


--target-name=MyTarget \

project-builder --command=update-project \

--project-name=MyProject

GUI


28/99

Ubuntu Mobile Guide

28 / 99

Figure 2.5: Project Builder GUI


29/99

Ubuntu Mobile Guide

29 / 99

2.7 Mobile Kernel

This kernel will specify a kernel configuration optimized for the smaller and more restricted hardware that is typically used by

mobile and embedded devices.

The generic kernel configuration is intended to cater for the wide variety of hardware devices found on desktop and laptopsystems. As such, the configuration specifies a large variety of devices and subsystems (e.g. ATM, SCSI drivers, filesystems)

which are not necessary for the UME project.

Design and Implementation

A reduced-config UME flavour will be added to the i386 flavour. This flavour will have all unnecessary or impossible config

options stripped out of it.

A new "lpia" arch will be added to the linux-image, linux-ubuntu-modules and linux-restricted-modules packages. The UME

flavour will be added to these for the "lpia" arch specifically customized for the initially targeted devices.

Flavour-specific configurations will be added to the linux-image, linux-ubuntu-modules, and linux-restricted-modules package,

in order to make it easier to build device-specific out of tree code for only one flavour.

Various third party patches may need to be applied for specific configs, for example from http://www.linuxpowertop.org/ or toadd SDIO support to the mmc layer. These will be assessed by the Kernel Team on a case-by-case basis.

2.8 Mobile Hardware Decode

Future chipsets will have the ability to do hardware accelerated video decode of MPEG-2, MPEG-4 (part 2), H.264 (MPEG-4

part 10) and VC-1 (WMV)


30/99

Ubuntu Mobile Guide

30 / 99

Figure 2.6: Overview of Architecture

Implementation of this spec will require a new package to provide the generic VA API in the form of libva. This library

communicates with the X server to find out which hardware specific driver will be needed and will then load that hardware

specific driver to do the actual work. libva will be open source licensed under a MIT style license.


31/99

Ubuntu Mobile Guide

31 / 99

Figure 2.7: Deliverables

The hardware specific driver that libva will open will be provided as part of the graphics driver.

2.9 Gnome Components

GNOME Mobile is a SW stack that is a subset of the GNOME Desktop platform. The components were put together by Nokia

and other companies involved in creating embedded systems. Details of their work is here: Gnome Mobile
http://www.gnome.org/mobilehttp://www.gnome.org/mobile


32/99

Ubuntu Mobile Guide

32 / 99

Figure 2.8: GNOME Mobile components

Matchbox: Window Manager

Pango: Text Layout

Cairo: 2D Rendering

ATK: Accessibility Toolkit

Gnome VFS: Virtual FS

BlueZ: Bluetooth

Telepathy: IM/Presence

GConf: Configuration

DBUS: IPC

GStreamer: Multimedia

E-D-S: Contacts / Calendar

Avahi: Service Discovery

2.10 Screen Keyboard

For text input on the go, Ubuntu mobile and embedded edition features a highly configurable on-screen keyboard.

The following mock-ups are examples of what can be done with the onBoard code, not direct suggestions for final layouts.

QWERTY As boring and inefficient as it is, Qwerty is something people will expect. To reduce the space requirements numbers

and symbols should be moved to a separate layer. Qwerty keyboards on small devices are usually best used with the stylus as the

keys tend to be small.

Mobile phone inspirate A keyboard that looks and works like a mobile phone keypad takes up much less space but is also less

efficient in use. As on a mobile phone, there are several letters on each key. Press a key several times in a row or for a certaininterval to get the second and third letters. The advantage is many people are already highly skilled at this form of text input.


33/99

Ubuntu Mobile Guide

33 / 99

Full sidepad This 5x7 key keypad contains all the letters in a typical alphabet plus some symbols and modifier keys. As with

Qwerty this keypad will likely require use of the stylus.

Figure 2.9: Keyboard

Frequency optimised sidepad This 4x5 keypad only has the 20 most commonly used letters of a given language in this case

English. The remaining 6 letters combined are only needed once every 5 keystrokes. These can be found on the sym layer

along with numbers and punctuation. Combinations of sym and shift yields 4 layers with 80 characters (of which 52+ are lower

and upper case alphabet). The advantage of this keyboard is that it is small but can still be operated efficiently with the thumb on

one hand.


34/99

Ubuntu Mobile Guide

34 / 99

Figure 2.10: Frequency Optimised Keyboard

2.11 Mobile Browser

The Mobile Internet Browser for UME will be a finger-navigable browser based on Mozilla. We will start with a recent version

of the Mozilla libraries using a recent Firefox 2.0+ tag. The browser will be re-chromed to match the look and feel of other UME

applications according to the UI Style Guide

Rationale

A xul-based browser with high-standards compliance and a strong community is desireable. Mozilla is the most obvious choice.

The only concern with a Mozilla-based solution is the performance on a resource-constrained device.

Goals for the browser include the following:

xul-based

strong community

strong adherence to standards

standard for all mobile internet devices

supports plugins

supports extensions

finger-navigable user interface

based on best-of-breed existing solution (Firefox)
https://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuidehttps://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuide


35/99

Ubuntu Mobile Guide

35 / 99

Minimo was investigated but after discussions with the maintainer (Doug Turner) we agreed that a Firefox-Mozilla base would

be appropriate given our constraints and device characteristics.

The Mobile Internet Browser will be based on Gecko 1.8+. Mozilla will release a new version based on Gecko (1.9) in the late

part of the year (Oct or November). At that time we can consider the steps to move the browser to this base.

Mozilla engineers have suggested that there may be some form of "Mozilla Mobile" solution down the road. This will beinteresting to track, contribute to, and leverage.

Mozilla can not offer engineering help on the browser work but they are supportive of the effort.

Ideally we would get a solution that would be embraced by the Mozilla community and eventually adopted as the "Firefox

Mobile" solution. However, Firefox brand sharing is not something that happens in the short term.

Scope

The project encompasses all of the tasks needed to get a Mozilla-based browser ported to the Hildon framework and included in

Ubuntu-mobile distribution.

Design

Browser design is a mix of existing Firefox features, Hildon application framework constraints, and UI Style Guide recom-mendations. The browser user interface will be redesigned to accomodate finger navigation and the small mobile device screen

(800x480 to 1024x600). Design wireframes include the following. These are recommendations. Actual implementation can vary

somewhat and also be progressive -- changing and improving in time.


36/99

Ubuntu Mobile Guide

36 / 99

Figure 2.11: Mobile Wireframe

Implementation

The following are the steps to completion of the mobile browser:

Selecting a branch of the Mozilla tree to use as the base browser. (Firefox 2.0.0.4 selected)

Build the project.

Re-brand and re-theme the browser, removing all reference to Firefox and all copyright material (e.g. help files). Make sure

that we are legally compliant with Mozilla guidelines.

Get the newly-named browser into Ubuntu-gutsy. (see Outstanding Issues below)

Begin porting to Hildon

Menu ported to top-left menu (replace Gtk calls)

Top-level window uses Hildon classes

Status bars and tabs at the bottom of the screen (hard task)

re-chrome other features

improve scrolling feature to be like wireframes with large thumb track

There is a lot of opportunity to divide and conquer the browser. We welcome help from any experts.


37/99

Ubuntu Mobile Guide

37 / 99

2.12 Mobile Graphics

X11 2D User Mode Driver

Mesa/DRI 3D User Mode Driver

Generic DRM kernel module with new memory management code

DRM chipset specific kernel driver module

Design

The drivers will be dependent on the the new DRM Video Memory Manager as described by: Video Memory Manager Also the

driver will therefore be dependent on Mesa 7, recently made available in Gutsy. Meas 3D The drivers require X Server 1.3 or

newer.

2.13 Power Management

Power optimization for PC Architecture is vastly different from that for embedded systems such as ARM based PDAs or Cell

phones. This is because each embedded chipset has its own unique set of power management features that require a custom flavor

of linux built from the ground up. PC based chipsets already have a well established code base in linux, with existing hardware

interfaces such as ACPI and HAL; and as they have evolved from desktops into smaller, more portable systems, a wealth of

software packages have been created to optimize power. Each of these packages can be thought of as a power micro-policy

controller for a specific subsystem on a linux based platform. For instance cpufreq manages power for the CPU supsystem, or

the iwconfig interface manages device specific power for the Network (WLAN) subsystem. Currently all these micro-policy

managers function independantly of one another and with little or no information from the user domain. Thus there are two

things lacking in linux with regard to power. The first is a centralized policy manager which can gather input from ACPI, the

user, and running applications to generate a complete picture of how the device is being used. This information can be used

to create macro-policies which can selectively tune or override the systems micro-policy managers to achieve far greater power

optimization. The second piece missing is a scheme to create micro-policy managers for all power-hungry subsystems that dontcurrently support any form of control.

Architecture usage model

Where is the user and device (e.g. stationary vs moving, near to vs from from a power source, inside or outside

When is the device being used (e.g. night vs day)

How is the device being used (e.g. is the user listening to it, looking at it, controlling it)

What is the device being used for (e.g. using network, playing audio, displaying video, high vs low performance)

Micro-policy focus is on the subsystem and driver level

Groupings by power optimization capability

CPU (single or multi-core)

Network (LAN, WLAN, WWAN)

Storage (Harddisk, Flashdisk, DVDROM)

Human Interface Devices (Mouse, Keyboard, Touchscreen)

Video (LCD, Graphics card

Audio (Speakers, Headphones, AC97, HD Audio)

Wireless Connections (Bluetooth, GPS)
http://www.tungstengraphics.com/mm.pdfhttp://www.mesa3d.org/http://www.mesa3d.org/http://www.tungstengraphics.com/mm.pdf


38/99

Ubuntu Mobile Guide

38 / 99

Architecture

The power policy manager for linux is meant to be a universal, cross-platform framework for reducing power consumption in

linux based devices; with particular focus on handhelds. It is implemented in three parts: a configuration data layer, a micro

policy engine control layer, and a daemon that ties the two together.

Configuration Layer: Provides configuration element messages from a GUI, applications, and system agents which describe

the optimization potential in the system. e.g. user focus, device position, handling, and movement, and application needs.

The Configuration Element Interface (CEI), will be based on Dbus and can be used by applications or a GUI to provide usage

model information to our power manager daemon. Usage model info is intended to help us understand where, when, how, and

for what purpose the device is being used. These attributes can help us intelligently regulate power and performance to match

the users neds and expectations.

MPE Layer: Provides tunable element control access to all the subsysems on the platform. e.g. LCD brightness, Audio codec,

etc. The MPE Interface (MPI), will be used to control any subsystem micro-policy managers which are already available to

us. Subsystems are determined as a collection of devices which serve some common purpose that can be optimized for power

cleanly. Micro-policy engines will exist for each subsystem we intend to control.

PPM Daemon: Defines what groupings of configuration elements are configuratble from the GUI, and the mappings between

configuration and tunable elements.

Constraints

No dependence on knowledge of specific applications or drivers

Should exist entirely in user space so theres no kernel dependency

Use C as the default programming language

Leverage established linux protocols and interfaces wherever possible


Should communicate with applications and GUI through a Dbus interface

Should use ACPI for system event notification

Configuration Input Layer

Configuration Element Interface (CEI)

The CEI will be implemented as a simple DBUS function call using the glib-dbus; wrappers. With this strategy, an xml file is

created which describes the function:

Using the dbus-binding-tool provided by glib we can then create a server and client header file that enables the usage of this

function. The function will look like this:

gboolean send_config_element(DBusGProxy*

proxy, char*

element, char*

target, char*

svalue,

int ivalue);


39/99

Ubuntu Mobile Guide

39 / 99

Element: is the string name of a predefined config element that the PPM Daemon will accept.vers

target: is the specific hardware target of the config element (hda1 for instance if there are more than one hd)

svalue: is the string data value, which is designed to be general and user friendly (like low, med, high)

ivalue: is the numerical data value, which is designed to be very specific (like X percent or X kbps)

The PPM Daemon will act as the server and the single receiver of the function call, and any number of applications or a GUI can

act as clients by sending elements out through this function. The ppmd server is called through the DBUS server connection, and

therefore must have the proper configuration files in place for the DBUS daemon to allow it to run.

Configuration Element List

These data points represent very specific conditions which may affect power or performance. Some can be used immediately for

obvious purposes, but some are just there as placeholders for some future benefit. The user will likely never provide this infor-

mation manually at this level. Usage model data at this granularity will be provided by the system (ACPI, HAL, Applications,

or the GUI in the form of a macro). Each type of input can be broken down into a set of specific "configuration elements" which

are what is actually sent across DBUS.

User Focus

These refer to how the user will interact with the MID. These represent the only things that the user MUST tell us.

Visual Attention

no visual (e.g. listening to a playlist of music)

intermittent visual (listening to music and picking songs)

constant visual (e.g. watching a video, playing a game)

Aural Attention

no audio (e.g. without headphones in a public place)

intermittent audio (e.g. waiting for IM alert)

constant audio (e.g. listening to music or watching a video)

Device control

no interaction (e.g. watching a movie, or listening to a playlist of music)

intermitent interaction (e.g. browsing the web, pausing to read)

constant interaction (e.g. playing a game)

Target Battery Life

1 hour (e.g. just enough for a meeting or class)

2 hours (e.g. just enough to watch a movie) 4 hours (e.g. just enough for a plane ride)

8 hours (e.g. enough for a work day)

maximum (as much as possible)

Device Position

These refer to the physical position and state of the MID. They are things that for the most part the user will have to enter, but we

can work to make most of these automatically detected

Device movement

stationary

moving


40/99

Ubuntu Mobile Guide

40 / 99

Config Element(string) Target(string) Value(string) Value(int)

videofocus lcdmon,extmon,exttv none,rare,intermittent,often,constantX ms (reaction time needed)

audiofocus speakers,headphones,ext none,rare,intermittent,often,constantX ms (reaction time needed)

userinput keypad,mouse,touchscr,cameranone,rare,intermittent,often,constantX ms (reaction time needed)

tgtbattlife all 1hour,2hour,4hour,8hour,max X minutes til off

Table 2.1: Energy Focus

* slowly (e.g. walking, jogging)

* intermittent high speed (e.g. in a car driving and stopping)

* constant high speed (e.g. in a plane or train)

Proximity/Accesstime to power source or wifi connectionDevice movement

Plugged in (ACPI Event)

* AC wall socket

* DC Car jack* DC Aeroplane jack

* DC Solar Charger

* External Battery

X minutes until power source/wifi available (ETA)

* immediately (e.g. in a car, at home, airport terminal)

* less than 20 (e.g. in transit between home and work)

* less than 120 (e.g. general mobile usage)

* less than 240 (e.g. a standard plane ride in coach)

* less than 480 (e.g. a standard college school day)

* very large (e.g. on a camping trip)

Device handling

is in a stable position (e.g. on a desk or on someones lap)

is being jostled (e.g. held while walking, or in a backpack)

Geographic Location (user input or GPS detection)

Country e.g. for cellular standards, radio freq ranges

Rural vs Urban e.g. likelihood of cell tower or recharge

Proximity to cell towers e.g. if one had a tower map

On Land vs Water e.g. likelihood of cell tower or recharge

Elevation e.g. too high for cellular

2.14 Power Thermal Optimizations

The platform thermal solution depends on the kernel framework for controlling the device performing state and monitor thermal

sensor for the platform. The kernel thermal monitoring and controlling mechanism is spread across acpi thermal driver and

non acpi thermal sensor driver, and the thermal algorithm are embedded in the kernel driver. The proposed patch is to extend

the thermal driver and unify various thermal sensing/controlling property through sysfs interface so that platform level thermal

related decision can be made at user space.

The current thermal zone driver is modified to expose thermal properties of platform through Sysfs. A new thermal Sysfs driver is

introduced which will export two interface for the platform specific sensor driver and component throttle driver. The cpu thermal

driver will work as it is, but will interface with the thermal Sysfs driver.


41/99

Ubuntu Mobile Guide

41 / 99

Linux notebooks today use a combination of ACPI and native-device thermal control. System uses ACPI CRT/HOT trip point for

critical system shutdown, since on a handheld, shutdown and hibernate to disk (if one even exists) are likely to be synonymous.

Active trip points are of no use on systems which have no fans. That leaves the single PSV trip point. ACPI 2.0 can associate

(only) a processor throttling device with a trip point. But the processor is not expected to always be the dominant contributor

to thermal footprint on handhelds like it often is on notebooks. ACPI 2.0 includes the _TZD method to associate devices with

thermal zones. However, ACPI does not say anything about how to throttle non-processor devices so that must be handled bynative device drivers.

Design

Thermal monitoring will be done using inexpensive thermal sensors polled by a low-power EC.

Thermal management policy decisions will be made from user space, as the user has a comprehensive view of the platform.

The kernel provides only the mechanism to deliver thermal events to user space, and the mechanism for user space to commu-

nicate its throttling decisions to native device drivers.

Figure 2.12: Thermal Control Software Stack

The thermal management policy control application sits on top. It receives netlink messages from the kernel thermal zone driver.

It then implements device-specific thermal throttling via sysfs. Native device drivers supply the throttling controls in sysfs and

implement device-specific throttling functions.

The thermal zone module has two components a thermal zone sysfs driver and thermal zone sensor driver

The thermal zone sysfs driver is platform-independent, and handles all the sysfs interaction. The thermal zone sensor driver is

platform-dependent. It works closely with the platform BIOS and sensor driver, and has knowledge of sensor information in the

platform.

The thermal sysfs driver exports two interfaces


42/99

Ubuntu Mobile Guide

42 / 99

(thermal_control_register()

and

thermal_control_deregister())

to component drivers, which the componentdrivers can call to register their control capability to the thermal zone sysfs driver.

The thermal sysfs drier also exports two interfaces:

* thermal_sensor_register() * thermal_sensor_deregister()

to the platform-specific sensor drivers, where the sensor drivers can use this interface to register their sensor capability. This

driver is responsible for all thermal Sysfs entries. It interacts with all the platform specific thermal sensor drivers and component

drivers to populate the sysfs entries. The thermal zone driver also provides a notification-of-temperature service to a component

driver. The thermal zone sensor driver as part of registration exposes its sensing and thermal zone capability.

Thermal Zone sensor driver

The thermal zone sensor driver provides all the platform-specific sensor information to the thermal sysfs driver. It is platform-specific in that it has prior information about the sensors present in the platform. The thermal zone driver directly maps the

ACPI 2.0 thermal zone definition. The thermal zone sensor driver also handles the interrupt notification from the sensor trips and

delivers it to user space through netlink socket. Component Throttle driver All the component drivers participating in the given

thermal zone can register with the thermal driver, each providing the set of thermal ops it can support. The thermal driver will

redirect all the control requests to the appropriate component drivers when the user programs the throttling level. Its is up to the

component driver to implement the thermal control. For example, a component driver associated with DRAM would slow down

the DRAM clock on throttling requests.

Thermal Zone Sysfs Property

The intent is that any combination of ACPI and native thermal zones may exist on a platform, but the generic sysfs interface looks

the same for all of them. Thus, the syntax of the files borrows heavily from the Linux hwmon subsystem. Each thermal zone

provides its current temperature and an indicator that can be used by user-space to see if the current temperature has changedsince the last read. If a critical trip point is present, its value is indicated here, as well as an alarm indicator showing whether it

has fired. If a passive trip point is present, its value is indicated here, as well as an alarm indicator showing whether it has fired.

There are symbolic links to the device nodes of the devices associated with the thermal zone. Those devices will export their

throttling controls under their device nodes.

Throttling Sysfs Properties

Devices that support throttling will have two additional properties associated with the device nodes: throttling and throttling_max.

A value of 0 means maximum performance, though no throttling. A value of throttling_ max means maximum power savings

in the deepest throttling state available before device state is lost. Events will be passed from the kernel to userspace using the

Linux netlink facility. Interrupts from the sensor or EC are delivered to user-space through a netlink socket.

sysfs ACPI Description R/W

temp1_input _TMP Current temerature RO

temp1_alarmTemperature change

occurredRW

temp1_crit _CRT Critical alarm temperature RO

temp1_crit_alarm Crtical alarm occurred RW

temp1_passive _PSV Passive alarm termperature RO

temp1_passive_alarm Passive alarm occurred RW

device_name1Link to device 1 associated

with zoneRO

device_name2Link to device 2 associated

with zoneRO

Table 2.2: Power Events Focus


43/99

Ubuntu Mobile Guide

43 / 99

2.15 Power Policies

Power optimization for PC Architecture is vastly different from that for embedded systems such as ARM based PDAs or Cell

phones. This is because each embedded chipset has its own unique set of power management features that require a custom flavor

of linux built from the ground up. PC based chipsets already have a well established code base in linux, with existing hardwareinterfaces such as ACPI and HAL; and as they have evolved from desktops into smaller, more portable systems, a wealth of

software packages have been created to optimize power.

Each of these packages can be thought of as a power micro-policy controller for a specific subsystem on a linux based platform.

For instance cpufreq manages power for the CPU supsystem, or the iwconfig interface manages device specific power for the

Network (WLAN) subsystem. Currently all these micro-policy managers function independantly of one another and with little

or no information from the user domain. Thus there are two things lacking in linux with regard to power. The first is a centralized

policy manager which can gather input from ACPI, the user, and running applications to generate a complete picture of how the

device is being used. This information can be used to create macro-policies which can selectively tune or override the systems

micro-policy managers to achieve far greater power optimization. The second piece missing is a scheme to create micro-policy

managers for all power-hungry subsystems that dont currently support any form of control.

Macro-policy focus is on the usage model

Where is the user and device (e.g. stationary vs moving, near to vs from from a power source, inside or outside

When is the device being used (e.g. night vs day)

How is the device being used (e.g. is the user listening to it, looking at it, controlling it)

What is the device being used for (e.g. using network, playing audio, displaying video, high vs low performance)

Micro-policy focus is on the subsystem and driver level

Groupings by power optimization capability

CPU (single or multi-core)

Network (LAN, WLAN, WWAN)

Storage (Harddisk, Flashdisk, DVDROM)

Human Interface Devices (Mouse, Keyboard, Touchscreen)

Video (LCD, Graphics card

Audio (Speakers, Headphones, AC97, HD Audio)

Wireless Connections (Bluetooth, GPS)

Architecture

The power policy manager for linux is meant to be a universal, cross-platform framework for reducing power consumption inlinux based devices; with particular focus on handhelds. It is implemented in three parts: a configuration data layer, a micro

policy engine control layer, and a daemon that ties the two together.

Configuration Layer: Provides configuration element messages from a GUI, applications, and system agents which describe

the optimization potential in the system. e.g. user focus, device position, handling, and movement, and application needs.

The Configuration Element Interface (CEI), will be based on Dbus and can be used by applications or a GUI to provide usage

model information to our power manager daemon. Usage model info is intended to help us understand where, when, how, and

for what purpose the device is being used. These attributes can help us intelligently regulate power and performance to match

the users neds and expectations.

MPE Layer: Provides tunable element control access to all the subsysems on the platform. e.g. LCD brightness, Audio codec,

etc. The MPE Interface (MPI), will be used to control any subsystem micro-policy managers which are already available to

us. Subsystems are determined as a collection of devices which serve some common purpose that can be optimized for power

cleanly. Micro-policy engines will exist for each subsystem we intend to control.


44/99

Ubuntu Mobile Guide

44 / 99

PPM Daemon: Defines what groupings of configuration elements are configuratble from the GUI, and the mappings between

configuration and tunable elements.

Figure 2.13: Power Policy Management Diagram

Constraints


Should exist entirely in user space so theres no kernel dependency

Use C as the default programming language

2.16 Media Player

The media viewer application for mobile devices. This is not the spec for the underlying engine (e.g. gstreamer, helix, etc). The

media player for UME will have a finger-navigable UI capable of viewing photos, playing music and videos, and using either

the gstreamer or helix media engines with a common interface to them. The UI will follow the recommendations in the UI Style

Guide

Rationale

There are some existing media applications but none seem to cover all of the features needed and be tailored for a MID, so a

new UI is being written. The goal is to simplify the media management on the MID and provide a single place for viewing and

listening to media.
https://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuidehttps://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuidehttps://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuidehttps://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuide


45/99

Ubuntu Mobile Guide

45 / 99

Gstreamer and Helix media engines will be supported with dynamic discovery of the content types supported by whichever

engine is present at runtime. Helix support is being included primarily for DRM solutions.

The entire scope of media management is large, from the first time a user obtains some content to consuming it on the device.

The following section describes the full spectrum with the ones outside the scope of this application shown in red. Additional

functionality may be added as time and resources permit.Comments welcome.

Functional Specification

PC = non-mobile device, such as a Linux or Windows desktop

MID = Mobile Internet Device.

Content = music files (mp3, etc), movies (.mpg, etc), photos (.jpg, etc)

Media viewer = Multimedia application on MID

1. Content Management on the PC

(Currently not planned) There are a few choices for music management on the PC (e.g. Windows Media Player, ITunes,

Banshee). For movie and photo management, users often use the filesystem directly. Eventually a new "MID Content

Manager" application could be written.

2. Getting content to the device

2.1 Syncing

* Auto-sync with an application that manages content on the PC. This involves writing a new plugin or application

that pushes the content from one of the following applications to the MID when the MID is plugged in via USB.

* Only sync down (all content is pushed to MID. Any MID content changes are lost

* Sync in both directions: content is merged on PC and MID. Conflicts are resolved by asking user for preference.

* Auto-sync with a file directory on the PC (just file system). Application registered when MID is plugged in to

USB to auto-sync contents.

Manual-sync: Plug MID into USB port. MID file system exposed to PC. User drags/drops files from PC to the

MID file system.

*

Sharing

* Auto-detect other MIDs in area via bluetooth. Connect. Display shared content from each MID on other MID. User

can download content to their MID.

Receive email with content. Save content to MID filesystem.

User Download on MID

On MID, download content from internet via the browser

On MID, download/upload content from wired or wireless connection to remote filesystem over network

Content Management on MID

User can:

View content name, artist, album, length, genre, music format, times played, last played date/time


46/99

Ubuntu Mobile Guide

46 / 99

View content as list

View content as thumbnails (album art for music, cover-art for movies or frame from movie, small image for photos)

View content as resizable thumbnails

View 3D-flipping album art

Select content

Select multiple files at the same time

Organize content folders, create new folders, name folders, move content between folders

* Assign content metadata: Name, Artist, Album, genre, cover art

* Auto-lookup music metadata online from CDDC: Name, artist, album, cover art

Create, delete, edit playlists

Sort music by: Name, Date, length, Artist, Album, genre, type (mp3, wav, etc)Slideshow

Create a slideshow of photos

Assign a music file to play when slideshow is started

Assign a music playlist to play when slideshow is started

Set the time delay between photo transitions

Set transition effect between pictures (fade, slide, etc)

Content Playback on MID

User can:

Play content

Pause content

Play content at double speed forward and backward

Play content at variable speed forward and backward

Jump to beginning of content

Jump to end of content

Stop content

View progress of content playbac

Documents

mobileguide-0.5