ubuntu mobile guide - the world's most popular free os | ubuntu

Ubuntu Mobile Guide WORKING PAPER 1 / 78

Ubuntu Mobile Guide

Ubuntu Mobile Guide WORKING PAPER

2 / 78

Copyright c© 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 ofcontributors, 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 derivativeworks 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 impliedwarranty 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.


3 / 78

COLLABORATORS

TITLE : REFERENCE :

Ubuntu Mobile Guide

ACTION NAME DATE SIGNATURE

WRITTEN BY September 3, 2007

REVISION HISTORY

NUMBER DATE DESCRIPTION NAME


4 / 78

Contents

1 Introduction 3

2 Developer Blueprints 4

2.1 Application Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Possible User Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Mobile User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Window Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Mobile Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6 Image Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.7 Mobile Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.8 Mobile Hardware Decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.9 Gnome Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.10 Screen Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.11 Mobile Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.12 Mobile Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.13 Power Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.14 Power Thermal Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.15 Power Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.16 Media Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.17 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.18 USB Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Image Creation for Mobile Devices 44

3.1 Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3 Supported devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.5 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.6 Install and Run Image Creator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.6.1 Instalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.6.2 Creating an Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45


5 / 78

3.6.2.1 Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.6.2.1.1 Start the image creator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.6.2.1.2 Create the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.6.2.1.3 Wait for the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.6.2.1.4 Create the target system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.6.2.1.5 Choose a functional set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.6.2.1.6 Generate image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.6.2.2 Using the command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.7 Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4 What is Hildon Desktop? 56

4.1 Hildon Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.1 The Hildon UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.2 hildon-desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.3 hildon-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.4 hildon-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.5 hildon-thumbnail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.6 libhildonmime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.7 gnomevfs-obex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.8 gnome-vfs-filechooser-backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.9 gtkfilesystemmemory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.10 hildon-thumbnail-libid3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.11 hildon-theme-plankton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.12 sapwood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.13 hildon-theme-cacher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.14 hildon-theme-layout-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.15 hildon-theme-tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.16 libosso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.17 hildon-home-webshortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.18 hildon-control-panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.19 clipboard-manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.20 maemo-launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.21 hildon-initscripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.22 osso-af-startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.23 hildon-help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.24 mce-dummy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.25 osso-af-settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.26 osso-af-utils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1.27 osso-app-killer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1.28 posix-locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1.29 gazpacho-hildon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1.30 hail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59


6 / 78

5 Anatomy of a Python Application in UME 60

5.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 Application files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3 Application Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

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

5.5 Executable file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.6 Main Python file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.7 Glade user interface file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.8 Icon file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.9 Sample make file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Glade with Python for UME Hildon 64

6.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3 Using Glade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.4 This Python program’s structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.5 Creating the Hildon Program and Hildon Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.6 Importing the .glade file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.7 Reparenting to Hildon Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.8 Getting the menu and making it a Hildon Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.9 Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.9.1 main.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.9.2 Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7 Application Development for UME - An Example 70

7.1 Location Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1.1 Flash UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1.2 The GeoClue backend. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

8 Theming and Customization of UME 77

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9 API References 78

9.1 D-Bus API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.2 GTK API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.3 Hildon API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.4 Gnome Developer Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78


7 / 78

List of Figures

2.1 Hildon Desktop Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Mobile Internet Device UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Mobile Internet Device UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Project Builder GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6 Overview of Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.8 GNOME Mobile components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.9 Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.10 Frequency Optimised Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.11 GNOME Mobile components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.12 Power Policy Management Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.13 Thermal Control Software Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.14 Power Policy Management Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.15 API Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3 Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.5 Functional Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.6 Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54


8 / 78

List of Tables

2.1 Energy Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2 Power Events Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Abstract

Welcome to the Ubuntu Mobile Guide! It contains information both on how to use and to develop software for the Ubuntu MobileEdition


1 / 78

About This Guide

Conventions

The following notes will be used throughout the book:

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

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

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

WarningA 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.

NotePDF, 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


2 / 78

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 leftmouse 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 thedesign 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 secondkey.

Contributing and Feedback

This book is developed by the Ubuntu Documentation Team. You can contribute to this document by sending ideas or commentsto 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 UbuntuBugtracker. Your help is vital to the success of our documentation!

Many thanks,

-Your Ubuntu Documentation Team

https://wiki.ubuntu.com/DocumentationTeam

https://wiki.ubuntu.com/DocumentationTeam

https://launchpad.net/products/ubuntu-doc/+bugs

https://launchpad.net/products/ubuntu-doc/+bugs


3 / 78

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 Ubuntuas a base. UME will extend Ubuntu by providing infrastructure for mobile development, with all of the necessary componentsintegrated 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 tothe Ubuntu Installation Guide.

Launchpad

HTML and PDF versions of the manual are available online at the Ubuntu Documentation website.

You can buy this guide in book form from our Lulu store. You will only pay for the price of printing and postage.

https://launchpad.net/~ubuntu-mobile

http://help.ubuntu.com

http://www.lulu.com/ubuntu-doc


4 / 78

Chapter 2

Developer Blueprints

Blueprints followed by Ubuntu Mobile developers during the development of the Ubuntu Mobile and Embedded Gutsy Edition

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-setupenvironment 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 applicationframework for the UME project. Mobile internet devices and tablets for which this distribution is targeted need an applicationframework that can provide a way to create applications with a very consistent look and feel and be prepared to run and interfacenicely 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


5 / 78

The Hildon Application Framework is one of a few existing frameworks designed for small devices and is a good candidate fortablet use. It has strong support from Nokia and will be separated from Maemo and become part of GNOME Mobile. This allowsthe 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, it’s 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 it’s 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 thehildon 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=/usrTHEME=${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-8export LC_ALL=en_GB.UTF-8export 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 \


6 / 78

-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, Firefoxwill be used. There is already efforts to reduce its footprint and currently we are running an internalversion. If we need to fit the browser into a very small profile machine a possible alternative is Opera. In a operational level, bothare 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

• Adobe Flash Player 9

• Adobe PDF Reader

• Java Runtime Environment(JRE)

• Media player. Currently it’s being considered Helix. Possible option: mplayerThe player going to support both helix andgstreamer simultaneously

Dictionary: Stardictseems to be the best option so far:

• Small

• Fast

• Flexible

• Bidirectional

• Lot’s of languages available.

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

E-mail: The specification asks for Thunderbird which is a great email application but I think that a better alternative is Clawswhichis a improved version of Sylpheed.

• Lightweight

• Fairly complete

• It’s already packed for Maemo so it’s easy for us to integrate.

http://www.mozilla.com/en-US/firefox/

http://www.opera.com/

http://browser.garage.maemo.org

http://uk.real.com/player/

http://www.mplayerhq.hu/design7/news.html

http://stardict.sourceforge.net/

http://www.claws-mail.org/

http://sylpheed.sraoss.jp/en/


7 / 78

• There’s 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 point at this time.

Recently we were pointed to a new email client called Modestwhich will become (but, as far as I can tell, there’s no officialposition on that) the new email application for Maemo.

Advantages

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

• It’s still under heavy development;

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

• It Doesn’t have all the possibilities as with Thunderbird or Claws and I understand that it will never have as it’s not the projecttarget.

Media Player

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

Camera

There is video capture applications (like xawtv, camE), programs that can read, record and process V4L devices like mplayerand videolan which can also be used to process the stream in realtime using filters and programs like EffecTV, GePhexandsnapshot applications like Camorama. I couldn’t find a single application that could do what we want, so I think that we coulduse something like Camorama as base and add continous video processing. Maemo uses gstreammer as the backend and theircamera 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 Cheesethat can be very handy. A Launchpadproject 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.

• It’s written in GTK.

• It’s 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 wasn’t able to make it work with 3 different cameras.

http://modest.garage.maemo.org/

http://docbook.wikiwikiweb.de/GePhex

http://live.gnome.org/Cheese


8 / 78

Ebook reader

There’s 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).

– OpenReaderformat (css and tables are not supported).

– Non-DRM’ed mobipocket format (tables are not supported).

– Plain text format.

Disadvantages

• Can’t read DRM’ed 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. That’s the wayit’s used in PepperPad.

• It can handle DRM’ed ebooks.

• There’s a very limitated number of formats supported. Currently only OpenEBook (OEB) besides itself.

Only for CHM there is alternatives like xchm and kchmviewer. Not very usefull anyway. There’s others like dotReader butmostly based on its own format or use Palmdoc/plucker only.

IM

Pidgin(formely known as Gaim) covers the specification out of the box with one exception, the Myspace IM protocol. There is apluginin the works, still alpha quality but it is already able to:

• Send and receive instant messages

• Buddy list support (basic support only)

• Looking up user information (in Get Info and tooltip text)

• (Some) formatting of incoming instant messages

Video Conferencing

Ekigais the preferred application in the specification.

• It covers the specification already.

• It’s a gnome application, so should not be difficult to integrate.

• Supports STUN.

http://docbook.wikiwikiweb.de/OpenReader

http://docbook.wikiwikiweb.de/MikhailSobolev

http://docbook.wikiwikiweb.de/PepperPad

http://pidgin.im/pidgin/home/

http://developer.pidgin.im/wiki/MySpaceIM

http://ekiga.org/


9 / 78

• It’s 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.

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 oldfilters or format converters that only could be used with very old Microsoft formats. At this moment I can foresee 2 possibilitiesrelated 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 editfiles

Advantage

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

Disadvantage

• It’s inconvenient to load the office application just to view a file.

TextMaker Viewer

There will be a commercial product called TextMaker Viewerthat fits very nicely but it does not exists yet and looks like to bebased on Qt.

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.html

http://supertuxkart.berlios.de/

http://supertux.lethargik.org/screenshots.html

http://tuxracer.sourceforge.net/

http://www.frozen-bubble.org/

http://www.pysol.org/


10 / 78

– 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

There’s plenty of them available. The more suitable ones for our needs are Lifereaand Straw. Both are quite equivalent butLiferea is starting to make incursions to integrate with blogs witch is an interesting feature. A second option is to use the oneintegrated into the email reader. Both Thunderbird and Claws suggested above can do it.

Clock

This item is just a matter of choosing what gadget would fit better into the current home applet environment as the requirementsare quite common except for the fact that it requires the clock to run full screen but this should not be difficult to achieve. Theoriginal Maemo’s panel clock or this clock appletcan do that. Another option is GPE’s clockthat is be an interesting option if theGPE PIM described below is chosen.

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

Remote desktop client

Currently, we have tsclientwhich is a wrapper that actually runs rdesktopand vncviewer on demand. This covers the specificationwith the exception of the listed functions:

• Scaling an panning: needs to be implemented on the clients but, despite not in the 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 someadditional 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.home.unix-ag.org/simon/files/n770/

http://gpe.linuxtogo.org/projects/gpe-clock.shtml

http://gpe.linuxtogo.org/

http://gpe.linuxtogo.org/projects/GPE-Contacts.shtml

http://gpe.linuxtogo.org/projects/GPE-calendar.shtml

http://gpe.linuxtogo.org/projects/gpe-sketchbook.shtml

http://gpe.linuxtogo.org/projects/GPE-soundbite.shtml

http://gpe.linuxtogo.org/projects/GPE-today.shtml

http://gpe.linuxtogo.org/projects/GPE-todo.shtml

http://gpe.linuxtogo.org/projects/gpe-timesheet.shtml

http://pimlico-project.org/

http://freshmeat.net/projects/tsclient/

http://www.rdesktop.org/


11 / 78

• Simple html-capable wysiwyg editor and posting tool (ftp and common blogging API’s)

Voip client

• Should be the same used for video conference?

– Ekiga

– Twinkle

– OpenWengo

GPS software / Navigation software

GeoClueseens to be a good starting point and there is a Maemo portalready.

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, Nokia’s Hildon ApplicationFramework was selected as the underlying application/UI framework. The UME user interface will look markedly different andbe 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/OpenWengo

http://www.freedesktop.org/wiki/Software/GeoClue

http://maemo.org/news/community/view/445e8586dc43867ee22def2915ee04cb.html


12 / 78

• 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 of100’s). 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 ApplicationFramework. The UME Home Screen consists of one or more panels containing panel widgets/applets, and a large open areacontaining home widgets/applets. The panel at the top is called the "Marquee". It is present when applications are running andcontains the application menu applet and close application applet. The number of panel and home widgets is restrained by spaceonly. It will be possible to configure the order and location of widgets. The Maemo UI also has these elements. Below is apicture showing these pieces:


13 / 78

Figure 2.3: Interface

Mobile Internet Device UI

Given the similarities in function and system characteristics to Nokia N-level hand-held devices, Nokia’s Hildon ApplicationFramework was selected as the underlying application/UI framework. The UME user interface will look markedly different andbe designed with user and OEM customization in mind.

Figure 2.4: Mobile Internet Device UI

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


14 / 78

• 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)

• Change the theme

• Create a home area plugin for navigation.

2.4 Window Manager

Mobile devices have smaller screens and usually do not have mice, so the normal WIMP (windows, icons, menus, pointer)paradigm isn’t a great fit. We therefore have to use a different window manager than usual.

A detailed description of the goals and guidelines have been compiled in the UI Application Design Guide

2.5 Mobile Architecture

• The new architecture name is lpia, this needs to be put into archtable in dpkg and apt.

• Architecture needs to be added to soyuz and buildds set up.

• Spec/default compilation flags to be provided by Intel. -mtune=pentium and gcc-4.1 is appropriate and gets us the neededoptimisations.

• The toolchain, including the headers from the kernel, is built and uploaded (usual two-stage bootstrapping procedure). Sinceit’s binary compatible with ia32 we will use that as a base rather than cross-compiling.

• Architecture is hooked into the normal build system and packages built there as usual.

• Packages-arch-Specific needs to have lpia added to it for packages that we want on lpia.

• A number of source packages require changes to debian/control to have lpia added to their Architecture line, as well asadjustments to debian/rules.

2.6 Image Creation

The development process for a mobile device tends to be different then the normal process used for workstation/laptops/servers,where the developer would not normally use the mobile device for their development environment, and where there is need togenerate a complete OS image from the developers working environment that is then installed on the target device.

In the case of the Ubuntu Mobile project, a complete set of built packages is available to the developer, so a lot of the complexitiesassociated with existing build-your-own-os-from-scratch project are just not needed. To bridge the remaining gap betweenUbuntu-Mobile development we use a new tool called project-builder

Features

There are three fundamental features that project-builder provides:

• The creation of a platform specific build environment

• The creation of platform specific target file-systems

• A user selectable "feature sets" (or fsets) to install bundles of packages that provide some high-level functionality

It also offers some additional advantages such as:

• The choice of a fully functional graphical user interface or a purely command line interface

http://ianlawrence.info/downloads/UME/MID_Application_UI_Design_Guide.pdf


15 / 78

• Wrappers for chrooting into a buildroot or target file-system(i.e. bind mounting important system directories and copying overnetwork configuration files)

• Wrappers for opening Xephyr windows for testing target file-systems

• 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 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

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, andPower-Management fsets

• After installing this fset, the target filesystem has enough functionality such that once installed on the target device, the devicecan boot to the ubuntu-mobile installation and automatically startup into the hildon desktop with the standard set of ubuntu-mobile applications


16 / 78

$ 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 islocated 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

• The "full-mobile-stack" is a meta fset that depends on the Core, Infrastructure, GNOME-Mobile, Mobile-Applications, andPower-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)


17 / 78

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 bootoptions 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

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 projectproject-builder -c delete-project --project-name build 2> /dev/null || true

# Kick off a clean projectproject-builder -c create-project \--platform-name $PLATFORM \--project-name build \--project-path $BUILDROOT \--project-description "Build system"

# Install a new target in the projectproject-builder -c create-install-usb \--project-name build \--target-name buildtarget \--image-name install.img

# Install the standard mobile stack in the targetproject-builder -c install-fset \--project-name build \--target-name buildtarget \--fset-name "full-mobile-stack"

# generate the an install USB imageproject-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. Fora list of available command line arguments, use the --help argument:


18 / 78

$ project-builder --helpUsage: project-builder [options]

Options:-c CMD, --command=CMDWhere 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_NAMEPlatform name--project-name=PROJECT_NAMEProject name--project-description=PROJECT_DESCProject description--project-path=PROJECT_PATHProject path-t TARGET_NAME, --target-name=TARGET_NAMETarget name--fset-name=FSET_NAMEFeature set identifier--image-name=IMAGE_NAMEName to use for target image file-q, --quiet don’t print status messages to stdout-d, --enable-debug Enable additional debug package while installing fsets-h, --help show this help message and exit

Examples:<Adding a new project>project-builder --command=create-project \--platform-name=’mccaslin’ \--project-name=’MyProject’ \--project-desc=’Example project’ \--project-path=/usr/src/projects/myproject

<Delete a project>project-builder --command=delete-project \--project-name=’MyOtherProject’

<Adding a new target to an existing project>project-builder --command=create-target \--project-name=’MyProject’ \--target-name=’MyTarget’

<Delete a target>project-builder --command=delete-target \--project-name=’MyProject’ \--target-name=’MyOtherTarget’

<installing an fset into a given target>project-builder --command=install-fset \--platform-name=’mccaslin’ \--project-name=’MyProject’ \--target-name=’MyTarget’ \--fset=’Core’ \

<change into a given project buildroot filesystem>project-builder --command=chroot-project \


19 / 78

--project-name=’MyProject’ \

<change into a given projects target filesystem>project-builder --command=chroot-target \--project-name=’MyProject’ \--target-name=’MyTarget’ \

<updating a given target inside a project>project-builder --command=update-target \--project-name=’MyProject’ \--target-name=’MyTarget’ \

<updating a given project>project-builder --command=update-project \--project-name=’MyProject’

GUI


20 / 78

Figure 2.5: Project Builder GUI


21 / 78

2.7 Mobile Kernel

This kernel will specify a kernel configuration optimized for the smaller and more restricted hardware that is typically used bymobile 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 configoptions stripped out of it.

A new "lpia" arch will be added to the linux-image, linux-ubuntu-modules and linux-restricted-modules packages. The UMEflavour will be added to these for the "lpia" arch specifically customized for the initially targetted 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-4part 10) and VC-1 (WMV)


22 / 78

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 librarycommunicates with the X server to find out which hardware specific driver will be needed and will then load that hardwarespecific driver to do the actual work. libva will be open source licensed under a MIT style license.


23 / 78

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 Nokiaand other companies involved in creating embedded systems. Details of their work is here: Gnome Mobile

http://www.gnome.org/mobile


24 / 78

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


25 / 78

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 numbersand symbols should be moved to a separate layer. Qwerty keyboards on small devices are usually best used with the stylus as thekeys 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 lessefficient 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.

Full sidepad This 5x7 key keypad contains all the letters in a typical alphabet plus some symbols and modifier keys. As withQwerty 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 caseEnglish; [WWW] source). The remaining 6 letters combined are only needed once every 5 keystrokes. These can be found onthe ’sym’ layer along with numbers and punctuation. Combinations of sym and shift yields 4 layers with 80 characters (of which52+ are lower and upper case alphabet). The advantage of this keyboard is that it is small but can still be operated efficiently withthe thumb on one hand.


26 / 78

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 versionof the Mozilla libraries using a recent Firefox 2.0+ tag. The browser will be re-chromed to match the look and feel of other UMEapplications 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/UIStyleGuide


27 / 78

Minimo was investigated but after discussions with the maintainer (Doug Turner) we agreed that a Firefox-Mozilla base wouldbe 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 latepart 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 "FirefoxMobile" 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 inUbuntu-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 varysomewhat and also be progressive -- changing and improving in time.


28 / 78

Figure 2.11: GNOME Mobile components

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 surethat 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.


29 / 78

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 thedriver will therefore be dependent on Mesa 7, recently made available in Gutsy. Meas 3D The drivers require X Server 1.3 ornewer.

2.13 Power Policy Management

Power optimization for PC Architecture is vastly different from that for embedded systems such as ARM based PDAs or Cellphones. This is because each embedded chipset has its own unique set of power management features that require a custom flavorof 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 ofsoftware packages have been created to optimize power. Each of these packages can be thought of as a power micro-policycontroller for a specific subsystem on a linux based platform. For instance cpufreq manages power for the CPU supsystem, orthe iwconfig interface manages device specific power for the Network (WLAN) subsystem. Currently all these micro-policymanagers function independantly of one another and with little or no information from the user domain. Thus there are twothings lacking in linux with regard to power. The first is a centralized policy manager which can gather input from ACPI, theuser, and running applications to generate a complete picture of how the device is being used. This information can be usedto create macro-policies which can selectively tune or override the systems micro-policy managers to achieve far greater poweroptimization. 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.pdf

http://www.mesa3d.org/


30 / 78

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 micropolicy 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 describethe 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 usagemodel information to our power manager daemon. Usage model info is intended to help us understand where, when, how, andfor what purpose the device is being used. These attributes can help us intelligently regulate power and performance to matchthe users neds and expectations.

• MPE Layer: Provides “tunable element” control access to all the subsysems on the platform. e.g. LCD brightness, Audiocodec, etc. The MPE Interface (MPI), will be used to control any subsystem micro-policy managers which are already availableto us. Subsystems are determined as a collection of devices which serve some common purpose that can be optimized for powercleanly. 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 betweenconfiguration and tunable elements.

Figure 2.12: Power Policy Management Diagram

Constraints

• No dependence on knowledge of specific applications or drivers


31 / 78

• Should exist entirely in user space so there’s 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 iscreated which describes the function:

<node name="/PPM"><interface name="com.intel.cei"><method name="SendConfigurationElement"><arg type="s" name="config_element" direction="in" /><arg type="s" name="target" direction="in" /><arg type="s" name="svalue" direction="in" /><arg type="i" name="ivalue" direction="in" />

</method></interface>

</node>

Using the dbus-binding-tool provided by glib we can then create a server and client header file that enables the usage of thisfunction. The function will look like this:

gboolean send_config_element(DBusGProxy *proxy, char *element, char *target, char *svalue, ←↩int ivalue);

• 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 canact as clients by sending elements out through this function. The ppmd server is called through the DBUS server connection, andtherefore 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 forobvious 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" whichare 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


32 / 78

– 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)

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

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 wecan work to make most of these automatically detected

• Device movement

– stationary

– moving

∗ 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


33 / 78

∗ 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 thermalsensor for the platform. The kernel thermal monitoring and controlling mechanism is spread across acpi thermal driver andnon acpi thermal sensor driver, and the thermal algorithm are embedded in the kernel driver. The proposed patch is to extendthe thermal driver and unify various thermal sensing/controlling property through sysfs interface so that platform level thermalrelated 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 isintroduced which will export two interface for the platform specific sensor driver and component throttle driver. The cpu thermaldriver will work as it is, but will interface with the thermal Sysfs driver.

Linux notebooks today use a combination of ACPI and native-device thermal control. System uses ACPI CRT/HOT trip point forcritical 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 contributorto thermal footprint on handhelds like it often is on notebooks. ACPI 2.0 includes the _TZD method to associate devices withthermal 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.


34 / 78

Figure 2.13: 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 andimplement 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 isplatform-dependent. It works closely with the platform BIOS and sensor driver, and has knowledge of sensor information in theplatform.

The thermal sysfs driver exports two interfaces

(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. Thisdriver is responsible for all thermal Sysfs entries. It interacts with all the platform specific thermal sensor drivers and componentdrivers to populate the sysfs entries. The thermal zone driver also provides a notification-of-temperature service to a componentdriver. The thermal zone sensor driver as part of registration exposes its sensing and thermal zone capability.

Thermal Zone sensor driver


35 / 78

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 theACPI 2.0 thermal zone definition. The thermal zone sensor driver also handles the interrupt notification from the sensor trips anddelivers it to user space through netlink socket. Component Throttle driver All the component drivers participating in the giventhermal zone can register with the thermal driver, each providing the set of thermal ops it can support. The thermal driver willredirect all the control requests to the appropriate component drivers when the user programs the throttling level. Its is up to thecomponent driver to implement the thermal control. For example, a component driver associated with DRAM would slow downthe 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 looksthe same for all of them. Thus, the syntax of the files borrows heavily from the Linux hwmon subsystem. Each thermal zoneprovides 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 ithas 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 theirthrottling 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 savingsin the deepest throttling state available before device state is lost. Events will be passed from the kernel to userspace using theLinux netlink facility. Interrupts from the sensor or EC are delivered to user-space through a netlink socket.

sysfs ACPI Description R/Wtemp1_input _TMP Current temerature RO

temp1_alarm Temperature changeoccurred RW

temp1_crit _CRT Critical alarm temperature ROtemp1_crit_alarm Crtical alarm occurred RWtemp1_passive _PSV Passive alarm termperature ROtemp1_passive_alarm Passive alarm occurred RW

device_name1 Link to device 1 associatedwith zone RO

device_name2 Link to device 2 associatedwith zone RO

Table 2.2: Power Events Focus

2.15 Power Policy Management

Power optimization for PC Architecture is vastly different from that for embedded systems such as ARM based PDAs or Cellphones. This is because each embedded chipset has its own unique set of power management features that require a custom flavorof 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 ofsoftware 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 theNetwork (WLAN) subsystem. Currently all these micro-policy managers function independantly of one another and with littleor no information from the user domain. Thus there are two things lacking in linux with regard to power. The first is a centralizedpolicy manager which can gather input from ACPI, the user, and running applications to generate a complete picture of how thedevice is being used. This information can be used to create macro-policies which can selectively tune or override the systems


36 / 78

micro-policy managers to achieve far greater power optimization. The second piece missing is a scheme to create micro-policymanagers 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 micropolicy 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 describethe 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 usagemodel information to our power manager daemon. Usage model info is intended to help us understand where, when, how, andfor what purpose the device is being used. These attributes can help us intelligently regulate power and performance to matchthe users neds and expectations.

• MPE Layer: Provides “tunable element” control access to all the subsysems on the platform. e.g. LCD brightness, Audiocodec, etc. The MPE Interface (MPI), will be used to control any subsystem micro-policy managers which are already availableto us. Subsystems are determined as a collection of devices which serve some common purpose that can be optimized for powercleanly. 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 betweenconfiguration and tunable elements.


37 / 78

Figure 2.14: Power Policy Management Diagram

Constraints


• Should exist entirely in user space so there’s 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). Themedia player for UME will have a finger-navigable UI capable of viewing photos, playing music and videos, and using eitherthe gstreamer or helix media engines with a common interface to them. The UI will follow the recommendations in the UI StyleGuide

Rationale

There are some existing media applications but none seem to cover all of the features needed and be tailored for a MID, so anew UI is being written. The goal is to simplify the media management on the MID and provide a single place for viewing andlistening to media.

Gstreamer and Helix media engines will be supported with dynamic discovery of the content types supported by whicheverengine is present at runtime. Helix support is being included primarily for DRM solutions.




38 / 78

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. Additionalfunctionality 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 ContentManager" 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 applicationthat 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 toUSB 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:


39 / 78

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

• 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 playback

• View time content has been playing

• Jump to location within the content by moving the progress thumb to a new location

Video

• Play full screen video

• Pause and restart full screen video without leaving full screen Audio

• Show visualizations while playing audio


40 / 78

• Show visualizations full screen while playing audio

• Start audio and play it in the background while performing other tasks

• Easily pause audio that is playing in the background

Photo

• Show photos full screen.

• Navigate to next and previous photos

• Play slideshow

• Pause full screen slideshow and restart without leaving full screen

Internet Radio

• User can:

• Create, edit, and delete internet radio stations

• Select a station and listen to streaming audio

• Add a new internet radio station from inside the browser.

Content Plugins

• Media viewer will support mechanism for applications to register for certain content types and show buttons to launch theseapplications when the content of the registered type is selected. Plugin applications will be started with the paths to all thecontent as command-line parameters. Examples include internet upload, email, or any application to manipulate content.

Theme / Skin

• Media viewer will use the system theme for all standard Hildon and GTK controls such as buttons, scrollbars, and dialogs.

• User can change the skin of the MID media viewer

Media Engine

• Media viewer will be capable of using gstreamer or helix media playback engines

• User can select which media engine to use first, or exclusively

• Media viewer will dynamically discover what content types each media engine supports and attempt to playback content onthe correct engine

• Media viewer will show a symbol on content that is not supported by any media engines

2.17 Utilities

This spec describes the configuration utilities and control panel for UME.

The user interface is built using the Hildon Application Framework. The framework provides for a control panel and controlpanel applets (or plugins). Each configuration utility will need to create a dialog-based configuration UI and a control panelapplet to launch the UI.

The use of the Hildon Application Framework directs the work and simplifies it at the same time. The process of creatingconfiguration utilities will be well-documented and straight forward.

Use Cases


41 / 78

The user wants to calibrate the screen. They go to Control Panel and select "Screen Calibration" The "Screen Calibrationconfiguration tool pops up. The user configures the screen and exist the Screen Calibration tool.

Scope

This spec does not cover the details for each of the configuration utilities. However, the following configuration utilities must becreated. (Ownership needs to be assigned):

• Date and Time

• Screen Calibration

• Sound configuration

• System information (name, system specs (mem, disk space tot/avail, etc)

• Language

Design

The Hildon Control Panel displays icons for plugins that are used to configure system settings. The control panel implements amodel for dynamic discovery. Correctly created, configured, and located plugins are automatically detected and displayed.

Implementation - Creating a control panel applet/plugin

The process of creating a control panel plugin is straight forward and entails creating a library with certain predefined methods,creating a corresponding .desktop file, and placing both in the right place on the system.

This [attachment:howto_write_control_panel_plugin.pdf] is a first-draft describing the process.

Outstanding Issues

Hildon control panel is not yet functional in Ubuntu. Nokia has some new "refactoring" code for control panel. This needs to bepackaged and added to gutsy.

2.18 USB Client

USB client controller driver, two gadget drivers of file-backed storage and CDC-EEM/RNDIS will be provided to end-user. File-backed storage gadget provides the host with an access to disk image on the client platform. CDC-EEM/RNDIS gadget makesthe client platform appear as a network adapter from the host stand point. Both Windows and Linux host system are supported.

API Framework


42 / 78

Figure 2.15: API Framework

The design is based on Linux USB gadget API framework. The peripheral controller driver implements the following functionsaccording to Poulsbo USB client controller hardware:

• Initialize/de-initialize the PCI resources (memory, interrupt and DMA)

• Handle the USB device enumeration and USB bus events

• Transmit the data packets through USB endpoints

• Call back the upper level USB client device driver whenever necessary

Mass storage gadget driver follows the protocol USB Mass Storage Bulk-Only Transport. It handles SCSI commands fromhost and USB requests bypassed from controller for device/config/interface descriptor setting. CDC-EEM/RNDIS gadget driverfollows Microsoft Remote NDIS Specification. It is responsible for the following operations:

• Provide the media state information to the host network stack by answering the RNDIS messages

• Works as an Ethernet interface device from remote host stand point of view, transmit the encapsulated 802.3 frames betweenhost and the simulated Ethernet network in the format of the RNDIS messages


43 / 78

• Monitor the USB bus events including connect, disconnect, suspend, resume, reset, and remote wakeup, and translate thoseevents to corresponding actions to the Showwell NDIS stack

• Communicate through the PCI Network Interface, which provides the network adapter instance to the upper network stack onthe client side OS

Utility provides end-user an easy way to use exposed device by gadget drivers. It will use samba service to mount shared imagefile and DHCP to set IP address.


44 / 78

Chapter 3

Image Creation for Mobile Devices

Creating an UME Image for your Device

3.1 Warning

This procedure was tested and worked as described. All the efforts will be taken to keep it up-to-date but bear in mind that it’sbased on software in development so your mileage may vary.

3.2 Summary

This document walks through the process of creating a working image for your mobile device using the Moblin Image Creatorutility, described in detail here. Running this image on a device will boot the Linux kernel, load the appropriate drivers, start X,show the UI, and allow you to launch applications.

3.3 Supported devices

The Image Creator currently allows you to create an image for a Samsung Q1 Ultra. However, having this device is not necessaryfor application development. For application or driver development, or to simply test run the UI, you can run everything usingXephyron your Linux workstation.

3.4 Development Environment

As described above, the having the target device is not really necessary. Just a PC workstation running a GNU/Linux will beenough. Theoretically, any recent Linux distribution should work but this procedure was tested on Ubuntu Gutsy Gibbon (future7.10) and 7.04. As a series of packages from the Gutsy repositories are need to build the project, a connection to the internet isrequired. To transfer the final image to the device, one will need a RW-CD or USB Pen Drive (>= 512MBytes).

3.5 Concepts

The Image Creator uses the concept of Projects that are linked to Platforms and one or more Targets that is comprised of one ormore "functional sets" or fsets. The Image Creator uses these elements to create an image. Each element is described below.

https://wiki.ubuntu.com/MobileAndEmbedded/ImageCreation

http://www.samsung.com/uk/products/mobilecomputing/ultramobile/np_q1_v000suk.asp

http://www.freedesktop.org/wiki/Software/Xephyr


45 / 78

• Project

A project is a platform-specific build environment with one or more targets. When you create a project, Image Creator createsa full Linux filesystem in the directory you specify. Chrooting into this directory creates an isolated environment where youcan develop software for your device. The environment includes apt tools, so you can install packages of the tools you need.The project directory includes one or more targets which are located in the <project location>/targets directory.

• Platform The platform is your target device. You select a platform when you create a project. This determines the kernel,system configuration, and device drivers that are made available as part of the targets you create within a project.

• Target The target is a platform-specific Linux filesystem, created in the /targets directory of your project. You create an imagefrom a target. One or more targets can exist for each project. Like projects, you can also chroot into this environment toconfigure it or copy applications from your project before making an image.

• Function/Feature Set (fset) A functional (or feature) set is a group of packages representing some functional area that ImageCreator can install on the target. An fset can have dependencies on other fsets. If you select to install an fset that depends onanother fset, the prerequisite fset will automatically be selected and installed on the target first.

• Image An image is a large (around 350MB) file created from a target. You can specify its name. An image can then be copiedto a device using a USB pen drive or CD.

3.6 Install and Run Image Creator

3.6.1 Instalation

Just run

apt-get install moblin-image-creator

3.6.2 Creating an Image

As described above, the image is the final result of the process. It’s what’s going to be used to install the file system that will runat the target device. There is two ways to create the image: using the GUI or using the command line. Both are described bellow.

3.6.2.1 Using the GUI

3.6.2.1.1 Start the image creator

•$ sudo image-creator

You will be presented with the main interface:


46 / 78

Figure 3.1: Interface

What matters for now at this moment is the Platform Project session. The three buttons are use to Add a project, Delete a projector to open a terminal chrooted into the project selected in case any manual changes are needed.


47 / 78

3.6.2.1.2 Create the Project

• Click the button Add and fill the options

– Name - Name of the project

– Desc - Description of this project (optional)

– Path - Where the projects and all related files will be placed

– Platform - Choose the target platform


48 / 78

Figure 3.2: Options


49 / 78

3.6.2.1.3 Wait for the installation

•

Figure 3.3: Install


50 / 78

The Image Builder is now creating the base project. This can take several minutes.

3.6.2.1.4 Create the target system

The next step is to create the target and add one or more functional sets. In this session of the interface we see the buttons Add, toadd a target to the current project, Add Functional Set, to include a functional set or more to the selected target, Delete, to deletea target from the list, Terminal, to open a chrooted terminal inside the target file system and Kernel cmdline that can be used toadd command line parameters to be used when the target kernel is executed.

• Name the target


51 / 78

Figure 3.4: Target


52 / 78

3.6.2.1.5 Choose a functional set

•

Figure 3.5: Functional Set


53 / 78

After the process is done, we will have a file system ready to be transfered to the target device or we can use the Terminal buttonto open a chrooted terminal and run the hildon environment directly in a Xephyr session.

3.6.2.1.6 Generate image

The last step, which can be optional, is to create the image for the target. There are five different image styles that can be created,attached to the five first buttons in this session of the interface:

• Live ISO - Create a live ISO image that can be burned to a CD. You can run boot this CD and run directly from it. Nothing iswritten to the target device.

• Install ISO - Also creates a ISO image but prepared to be installed to the target device. If you boot using the resulting CD,your device will be partitioned and the image installed automatically. Beware.

• Live USB - Create a live USB image that can be burned to a USB drive. As in the Live ISO, you can run boot and run directlyfrom it. Nothing is written to the target device.

• Live RW USB - Same as above but it supports data persistence. Every change made on the system while running this imagewill be saved on the USB drive.

• Install USB - Same as Install ISO but the image will be suitable to install in a USB drive.


54 / 78

Figure 3.6: Image

Currently, only the Install USB image type is supported. Once the generation of the image is done, use the Write USB Imagebutton to write it to your USB drive.


55 / 78

3.6.2.2 Using the command line

As stated before, the same steps above can be done using the command line. This is very handy once the parameters are alreadydefined as we can process the whole projects in batch. The steps taken can be as simple as follows:

1. Create the Project

•$ sudo image-creator -c create-project \

--platform-name mccaslin \--project-name "myproject" \--project-path "/usr/src/myproject" \--project-description "My Samsung Q1 Ultra project"

2. Create the target system

•$ sudo image-creator -c create-target \

--project-name "myproject" \--target-name "target1"

3. Install the functional set.

•$ sudo image-creator -c install-fset \

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

4. Create the image

•$ sudo image-creator -c create-install-usb \

--project-name myproject \--target-name target1 \--image-name myproject_target1_install-usb.img

Once finished, a file called myproject_target1_install-usb.img will have the image ready to be burn to a USB drive and beinstalled in the target. Another option is to chroot to the generated file system with:

•$ sudo project-builder -c chroot-target \

--project-name myproject \--target-name target1

And from there run the hildon-desktop with pointing to a Xephyr instance.

3.7 Outstanding Issues

• - Since the moblin-image-creator needs to create rootstrap images in the debian package build process, then it needs to haveroot privileges. A default pbuilder configuration will attempt to build the package as a non-root user (for a lot of good reasons.)Unless the Ubuntu build is configured to run as root, then this packages debian rules will need to be reworked. - The image-creator has a nasty bug that makes it crash if any fset different from "core" is selected.


56 / 78

Chapter 4

What is Hildon Desktop?

Mobile internet devices and tablets need a desktop framework that can provide a way to create applications with a very consistentlook 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, applications should be designed for touchscreen use, finger-friendly navigation,gestures, etc.

The Hildon Application Framework is one of a few existing frameworks designed for small devices and is a good candidate fortablet use. It has strong support from Nokia and is a part of GNOME Mobile. This allows the Gnome community and others tocontribute in a way that benefits all users.

4.1 Hildon Desktop

Our major goal is to make it easy for distributions to package Hildon Desktop so that developers can have a quick-to-setupenvironment for the development of plugins

4.1.1 The Hildon UI

The following is in somewhat prioritized order (from top down) to reach what is known as the Hildon UI. .

4.1.2 hildon-desktop

Hildon Desktop is the main UI component of the Maemo UI. It consists of two panels and the Home area. Each panel can houseplugins and basically function like on an ordinary desktop environment except for that this user interface was designed for touchscreen use on mind and was originally developed to Nokia 770 Internet tablet. Build-Depends: libhildon1-dev, libosso-dev,osso-af-settings, libhildonfm2-dev, libhildonhelp-dev Very closely tied with hildon-theme-plankton. .

4.1.3 hildon-1

The Hildon widgets. Contains generic application window as well as several specialized widgets designed for internet tablets.Very closely tied with hildon-theme-plankton. .

4.1.4 hildon-1

File management widgets. Implementation of GtkFileChooser designed for internet tablets. Build-Depends: libosso-dev, maemomodified gtk+ (for exporting parts of GtkFileSystem), libhildon-thumbnail-dev, osso-gwconnect-dev, mce-dev, libhildon1-dev,libhildonmime-dev .


57 / 78

4.1.5 hildon-thumbnail

API for getting thumbnails for files. Similar to GnomeThumbnailFactory but asynchronous, designed for low memory lowperformance devices. Includes thumbnailer plugin for files supported by GdkPixbuf. Build-Depends: libosso-dev .

4.1.6 libhildonmime

API for activating applications to handle certain MIME types. Similar to gnome_vfs_url_show() but uses X-Osso-Service fieldin .desktop files and activates applications with DBus directly. Includes hildon-update-category-database which is update-mime-database (from shared-mime-info) modified to recognize additional elements. .

4.1.7 gnomevfs-obex

obex:// module for gnome-vfs Build-Depends: libopenobex1-dev, libgwobex-dev, osso-gwconnect-dev .

4.1.8 gnome-vfs-filechooser-backend

gnomevfs backend for GtkFileChooser .

4.1.9 gtkfilesystemmemory

GtkTreeStore which can be used as a in-memory file system backend for hildon-fm. Build-Depends: maemo modified gtk+ (forexporting parts of GtkFileSystem) .

4.1.10 hildon-thumbnail-libid3

hildon-thumbnail plugin for audio files (as supported by libid3.) (This is actually abusing the thumbnailing API by using thethumbnail for passing metadata about the audio files.) Build-Depends: libhildon-thumbnail-dev .

4.1.11 hildon-theme-plankton

The plankton theme (matchbox + gtk) Contains one big png which when built with the layout and tools produces a standalonetheme package. Build-Depends: hildon-theme-layout-4, hildon-theme-tools .

4.1.12 sapwood

The theme engine. Similar to pixbuf engine but uses client-server design and pixmaps rather than pixbufs. Faster and morememory efficient than pixbuf engine, but doesn’t do scaling or gradients. .

4.1.13 hildon-theme-cacher

A tool for generating a bytecode-ish cache file for gtkrc files to improve application startup time. Depends on maemo modifiedgtk+ (though the support for caching is actually missing at the moment.) .

4.1.14 hildon-theme-layout-4

gtkrc template for themes. The idea is that we maintain single gtkrc template (which is closely tied with the code) and implementdifferent themes by only drawing a single png file. Build-Depends: hildon-theme-tools .


58 / 78

4.1.15 hildon-theme-tools

Tools for handling the theme building process. .

4.1.16 libosso

DBus convenience wrappers and hardware related callbacks. Build-Depends: mce-dev .

4.1.17 hildon-home-webshortcut

Plugin for hildon-desktop, shows a an image and opens a URL in browser when clicked. Build-Depends: libhildon1-dev, libosso-dev, osso-af-settings, libconic0-dev, libhildonfm2-dev, libhildonmime-dev, libhildondesktop-dev, hildon-desktop-dev .

4.1.18 hildon-control-panel

Control panel shell roughly similar to gnome-control-center. Control panel plugins are shared libraries rather than executables tosave memory. Build-Depends: libhildon1-dev, libosso-dev, osso-af-settings, libhildonhelp-dev .

4.1.19 clipboard-manager

Subset of gnome-settings-daemon functionality, namely the cliboard manager to retain the clipboard contents after applicationexit and GConf-Xsettings bridge for a couple of settings .

4.1.20 maemo-launcher

Application startup time optimizer, a bit similar to kdeinit. Taking advantage of maemo-launcher doesn’t require code changes,merely recompile. .

4.1.21 hildon-initscripts

Startup script, settings and environment variables for running gtk and matchbox with proper look and feel. Depends: osso-af-startup .

4.1.22 osso-af-startup

Startup scripts for for target device. Depends: osso-af-utils, osso-core-config .

4.1.23 hildon-help

API for integrating with help UI. (The UI is closed source, but it may be possible to use yelp instead.) Build-Depends: libosso-dev, libhildon1-dev .

4.1.24 mce-dummy

Dummy package to satisfy package dependencies for mce. .

4.1.25 osso-af-settings

Contains pkgconfig file providing directories where to put application, task navigator, status bar, home .desktop files, etc. .


59 / 78

4.1.26 osso-af-utils

Small utilities, for booting up and periodically cleaning up temporary files. Includes transparent cursor theme to hide the pointer.

4.1.27 osso-app-killer

Scripts for clearing user data and settings, resetting factory settings, shutting down application before running restore..

4.1.28 posix-locales

Locale data for languages

4.1.29 gazpacho-hildon

Hildon support for Gazpacho UI builder

4.1.30 hail

Accessibility support for hildon-1 and hildon-fm Build-Depends: hildon-libs-dev, hildon-fm-dev


60 / 78

Chapter 5

Anatomy of a Python Application in UME

5.1 Purpose

This chapter describes the files and directories you need to know about to add a Python application to the UME Hildon Desktop(Applications) > Extras menu.

• The first section lists the files an application needs to be discovered, presented, and launched by the Desktop.

• The next section explains the "application directory" that contains source code and other application-specific files.

• The complete set of files that makeup a sample Python application is detailed.

• A sample make file is provided.

5.2 Application files

Each Python application requires the following files:

• Desktop file -- Describes the application to the UME Desktop. The presence of this file in the right location informs theDesktop that the application exists and provides information necessary to display it in a menu and launch it.

• Executable file -- The file the Desktop runs to execute the application. For Python applications, this is a shell script thatlaunches the Python interpreter and is passed the application’s main Python file.

• Main Python code file -- The main python file for the application

Additional optional files may include the following:

• Additional Python or other application-specific files

• Glade user interface file(s) -- The XML file(s) produced with Glade and imported into Python that describes the application’suser interface objects

• Icon -- The icon displayed in menus to represent the application before it is launched.

Before taking a closer look at these files, let’s take note of an application’s dedicated "application directory."


61 / 78

5.3 Application Directory

"Core" application-specific files (those that are not related to registering the application with the Desktop or displaying it in theuser interface prior to launching) reside in a dedicated "application directory."

The application directory contains:

• The main Python file

• Any other application-specific files your code may need, such as other Python files or your Glade user interface descriptionfile(s)

The application directory is a subdirectory of:

• /usr/share

In the example explained here, the application’s directory is named pyglade, as follows;

• /usr/share/pyglade

For the sample application considered in this wiki page, this directory contains the following:

• main.py -- the main Python file

• pygladeui.glade -- the Glade user interface description file

Now, let’s take a tour of the actual files, starting with the critical .desktop file.

5.4 Application auto-discovery via the .desktop file

The Desktop automatically discovers applications that have a .desktopfile in the /usr/share/applicationsdirectory. This file alwaysstarts with "[Desktop Entry]" and continues with a number of key value pairs that define the application to the Desktop, including:

• the file name of the application’s executable -- the Execkey

• the name of the the application to display in the applications menu -- the Namekey

• the file name (without the file extension) of the icon to display along with the name in the applications menu, if any -- theIconkey

Here’s a sample .desktop file:

[Desktop Entry]Version=1.0.0Encoding=UTF-8Name=PyGladeType=ApplicationExec=/usr/bin/pygladeTerminal=falseIcon=pyglade_26Categories=Applications

Currently, applications with a valid .desktop file are presented to the user in the (Applications) > Extras menu.

The executable and icon files are described below.


62 / 78

5.5 Executable file

The Desktop doesn’t launch Python files directly. Instead, the Desktop launches the executable specified with the Execkey in the.desktop file. This executable is usually a simple shell script that does two things:

• it switches to the application’s directory

• it launches Python and passes it the application’s main Python file (which resides in the application’s directory).

Here are details:

Run time location: /usr/bin

File name extension: Can be anything

Example: /usr/bin/pyglade

Type: For Python applications, this is generally an executable shell script.

Sample:

#!/bin/shcd /usr/share/pygladepython main.py

Key points:

• /usr/share/pygladeis the application directory that contains the application’s Python code

– Note: as with all other run-time paths, this path is relative to the UME’s root (or the chroot when working in an Image-Creator target).

• python main.pylaunches the Python interpreter and passes it the application’s Python file, namely main.py

5.6 Main Python file

This is the application’s main Python file.

Run time location: The ApplicationDirectory

File name extension: Can be anything, typically is .py

Example: /usr/share/pyglade/main.py

Type: Python file

5.7 Glade user interface file

This optional file defines the application’s GTK user interface objects. Such files are created using Glade and imported into yourPython code, after which its GTK objects can be accessed and used in Python.

Run time location: The ApplicationDirectory

File name extension: .glade

Example: /usr/share/pyglade/pygladeui.glade

Type: Glade definition file


63 / 78

5.8 Icon file

This is the optional icon that is displayed in the UME applications menu next to the application name.

Run time location: /usr/share/icons/hicolor/22x22/

File name extension: .png

Example: /usr/share/icons/hicolor/22x22/pyglade_26.png

Type: PNG, SVG

5.9 Sample make file

Here’s the make file I used to install the sample application referred to in this page. (Setting up a build environment with anexternal source directory mounted to the target is beyond the scope of this page.)

BINDIR = ${DESTDIR}/usr/bin/APPDIR = ${DESTDIR}/usr/share/pygladeall:install:

@mkdir -p ${BINDIR}@mkdir -p ${APPDIR}@install -m 755 -D main.py ${APPDIR}/main.py@install -m 755 -D pygladeui.glade ${APPDIR}/pygladeui.glade@install -m 755 -D executable.txt ${BINDIR}/pyglade@install -m 755 -D desktop.txt ${DESTDIR}/usr/share/applications/pyglade.desktop@install -m 755 -D pyglade_26.png ${DESTDIR}/usr/share/icons/hicolor/22x22/apps/ ←↩

pyglade_26.png

clean:@rm -f ${APPDIR}/main.py@rm -f ${APPDIR}/ui.glade@rm -f ${BINDIR}/pyglade@rm -f ${DESTDIR}/usr/share/applications/pyglade.desktop@rm -f ${DESTDIR}/usr/share/icons/${THEME}/22x22/apps/pyglade_26.png


64 / 78

Chapter 6

Glade with Python for UME Hildon

6.1 Purpose

This chapter explains how to import an application’s user interface that was made with Glade into Python in order to make aUME/Hildon application. In particular, it covers:

• How to import a Glade user interface definition file into Python

• How to access objects defined in Glade and give them local Python names

• How to reparent Glade widgets to the required Python Hildon Window

• How to get a GTK Menu defined in Glade and set it as the Hildon Program menu in Python

Terminology: What’s "reparenting"? The top level window in a UME application is - by definition - a Hildon Window. However,Glade can only create a GTK Window, not the Hildon Window you need. (When using Glade, you need a GTK Window as atop-level widget so that you can add other child widgets to it). To deal with this mismatch, you create a real Hildon Window inyour Python and then "reparent" the GTK Window’s direct children to it.

6.2 Prerequisites

• Glade

• A UME development/build/run environment

• Understanding of the files and directories required by a UME Desktop Python application -- see Anatomy of a Python Appli-cation in UME

• Basic Python knowledge

6.3 Using Glade

This how-to assumes basic knowledge of how to use Glade. However, even if you’ve never used it before, rest assured that it’squite easy.

Glade is a graphical tool for creating a GTK user interface by dragging widgets onto a canvas or into other widgets (in whichcase they become children) and then optionally selecting widgets and modifying their properties. The result is an XML filewith the .gladeextension that contains a description of the user interface that can be imported into various languages, including


65 / 78

Python. After importing the .glade file, you can access the widgets using the names you gave them in Glade and then use themprogrammatically.

As noted, one important point is how to deal with the fact that Glade cannot create a Hildon Window. It can only create a GTKWindow, and indeed it requires one as a parent for most other widgets (but not menus). So, in Glade, you create the GTK Windowand add widgets to it, then, in your Python you "reparent" the GTK Window’s child widgets to your real Hildon Window. Tominimize reparenting, this example program’s root window has only one child, a GTK VBox widget, which in turn contains childwidgets. So, this VBox must be reparented from the GTK Window to a Hildon Window.

Let’s take a look at these steps in a little more detail, but first let’s review the Python program’s basic structure.

6.4 This Python program’s structure

Note: Please see main.py sourceat the end of this page.

This is a simple Python program.

Among the usual imports at the top is: import gtk.glade, which is required to import the .glade file.

The program has one class, GladeTestApp, whose constructor creates the Hildon Program and Hildon Window, imports the .gladefile, assigns Glade objects local names, reparents a widget, sets the Hildon program menu from a Glade-defined menu, sets upsignal handlers for user events, and other things.

The class is instantiated as an object named app, and it’s run()method is executed.

Let’s start by examining how the constructor creates the Hildon Program and Hildon Window.

6.5 Creating the Hildon Program and Hildon Window

Here’s the top of the GladeTestAppclass, showing the beginning of its constructor.

class GladeTestApp():"""pygtk-glade-hildon demo project"""

def __init__(self):

#make the hildon programself.program = hildon.Program()self.program.__init__()

#make the hildon window and add to programself.window = hildon.Window()self.window.set_title("PyGlade")self.program.add_window(self.window

As you can see, the Hildon Program is created and assigned to self.program. And, the Hildon Window is created and assigned toself.window. Pretty straightforward.

Next, we’ll import the .glade file.

6.6 Importing the .glade file

The .glade file is imported inside GladeTestApp’s constructor. The code looks like this:


66 / 78

self.glade_file = "pygladeui.glade"self.wTree=gtk.glade.XML(self.glade_file)

The first line defines a variable ( self.glade_file) and assigns it the file name of the .glade file, in this case pygladeui.glade.

The second line actually imports all user interface objects from the specified .glade file into a new variable named self.wTree.

Now, all the objects defined in the .glade file can be retrieved from self.wTreeand can be assigned local names for programmaticuse. They are retrieved using the names they were given (or assigned by default) when using Glade, as shown next.

6.7 Reparenting to Hildon Window

As noted, the GTK window made with Glade contains a GTK VBox widget that contains all other application widgets (exceptfor the menu, discussed below). When making this VBox widget with Glade, I gave it the following name: vbox1. (The widget’sname is viewed/set in Glade by selecting it and looking at its "properties" in the Properties window.)

Here’s the Python code that fetches the VBox from the imported glade file:

#reparent the vbox1 from glade to self.windowself.vbox1 = self.wTree.get_widget("vbox1")self.reparent_loc(self.vbox1, self.window)

The first non-comment code line gets the specified GTK VBox and assigns it to the self.vbox1variable.

The second reparents the VBox from the GTK window made in Glade to the Hildon Window made in Python that’s namedself.windowwith the reparent_loc()function.

That’s it for reparenting! Let’s take a look at importing the GTK menu made in Glade and setting it as the application’s Hildonmenu.

6.8 Getting the menu and making it a Hildon Menu

In Hildon, you create a GTK menu and add it to the Hildon Program with the set_common_menu(GTK.menu)function, asmentioned previously.

The following Python code shows how to get the imported the GTK menu that’s named menu1, assign it to self.menuGlade, andthen set the Hildon Program to use this as its common menu.

#get menu from glade and reparent as common menu in hildon programself.menuGlade = self.wTree.get_widget("menu1")self.program.set_common_menu(self.menuGlade)

6.9 Source

6.9.1 main.py

import pygtkimport gtkimport hildonimport gtk.glade


67 / 78

class GladeTestApp():"""pygtk-glade-hildon demo project"""

def __init__(self):

#make the hildon programself.program = hildon.Program()self.program.__init__()

#make the hildon window and add to programself.window = hildon.Window()self.window.set_title("PyGlade")self.program.add_window(self.window)

#receive signal to close window from framework close buttonif (self.window):

self.window.connect("destroy", gtk.main_quit)

#import the glade file and assign to self.wTreeself.glade_file = "pygladeui.glade"self.wTree = gtk.glade.XML(self.glade_file)

#reparent the vbox1 from glade to self.windowself.vbox1 = self.wTree.get_widget("vbox1")self.reparent_loc(self.vbox1, self.window)

#get menu from glade and reparent as common menu in hildon programself.menuGlade = self.wTree.get_widget("menu1")self.program.set_common_menu(self.menuGlade)

#get quit menu item and connect signalself.menuItem_quit = self.wTree.get_widget("quit1")self.menuItem_quit.connect("activate", gtk.main_quit)

#get hbox1 in order to modify contents based on user actionsself.hbox1 = self.wTree.get_widget("hbox1")

#get label1 for useself.label1 = self.wTree.get_widget("label1")

self.controlBar = hildon.Controlbar()self.controlBar.set_min(0)self.controlBar.set_max(50)self.controlBar.set_value(15)self.controlBar.connect("value-changed", self.control_changed, self.label1)

self.menuItem_controlBar = self.wTree.get_widget("controlBar")self.menuItem_controlBar.connect("activate", self.controlBar_pressed, self.hbox1, ←↩

self.controlBar, self.label1)

self.dateEditor = hildon.DateEditor()self.dateEditor.set_year(2006)self.dateEditor.set_month(4)self.dateEditor.set_day(20)

self.menuItem_dateEditor = self.wTree.get_widget("dateEditor")


68 / 78

self.menuItem_dateEditor.connect("activate", self.dateEditor_pressed, self.hbox1, ←↩self.dateEditor, self.label1)

#get button1 and connect a signal handlerself.button1 = self.wTree.get_widget("button1")if (self.button1):

self.button1.connect("pressed", self.button1_pressed, self.label1)

#destroy the gtk window imported from gladeself.gtkWindow = self.wTree.get_widget("window1")self.gtkWindow.destroy()

#display everythingself.window.show_all()

def run(self):gtk.main()

# signal handlers

def menuItem_quit1_pressed(self, widget):gtk.main_quit

def button1_pressed(self, widget, label):label.set_label("new label")

# controlBar

def controlBar_pressed(self, widget, hbox, controlBar, label):self.dechild_hbox(hbox)hbox.add(controlBar)controlBar.show()label.set_text("ControlBar")

def control_changed(self, widget, label):label.set_text(" %s of %s" % (widget.get_value(), widget.get_max()))

# dateEditor

def dateEditor_pressed(self, widget, hbox, dateEditor, label):self.dechild_hbox(hbox)hbox.add(dateEditor)label.set_text("DateEditor")dateEditor.show()

#utility

def dechild_hbox(self, hbox_widgets):children = hbox_widgets.get_children()for child in children:

hbox_widgets.remove(child)


69 / 78

def reparent_loc(self, widget, newParent):widget.reparent(newParent)

if __name__ == "__main__":app = GladeTestApp()app.run()

6.9.2 Makefile

BINDIR = ${DESTDIR}/usr/bin/APPDIR = ${DESTDIR}/usr/share/pygladeall:install:

@mkdir -p ${BINDIR}@mkdir -p ${APPDIR}@install -m 755 -D main.py ${APPDIR}/main.py@install -m 755 -D pygladeui.glade ${APPDIR}/pygladeui.glade@install -m 755 -D executable.txt ${BINDIR}/pyglade@install -m 755 -D desktop.txt ${DESTDIR}/usr/share/applications/pyglade.desktop@install -m 755 -D pyglade_26.png ${DESTDIR}/usr/share/icons/hicolor/22x22/apps/ ←↩

pyglade_26.png

clean:@rm -f ${APPDIR}/main.py@rm -f ${APPDIR}/pygladeui.glade@rm -f ${BINDIR}/pyglade@rm -f ${DESTDIR}/usr/share/applications/pyglade.desktop@rm -f ${DESTDIR}/usr/share/icons/${THEME}/22x22/apps/pyglade_26.png

re.


70 / 78

Chapter 7

Application Development for UME - An Example

7.1 Location Services

Its recommended to have a look on this post if you are not familiar with Moblin, before getting started. This is a work in progressand pulls from upstream code such as Moblin and GeoClue.

7.1.1 Flash UI

Begin by checking the UI out from the repo:

vern@N800-hacker:~$ mkdir flash;cd flash

vern@N800-hacker:~/flash$

vern@N800-hacker:~/flash$ git clone rsync://moblin.org/repos/projects/mobile-basic-flash. ←↩git

[you need git-core if you do not have it ... apt-get install git-core] the above commands create a folder mobile-basic-flash:

vern@N800-hacker:~/flash$ cd mobile-basic-flash

This folder has the structure:

autogen.sh

configure.ac

content

COPYING

debian

Makefile.am

po

src

Inside the ’src’ folder are the source .fla and Action Script .as files. Inside the ’content’ folder are the compiled .swf files, theHTML page which embeds the flash movie (called flash_home.html), and ’backgrounds’ and ’icons’ folders which should beobvious. There is also the file conf.xml which is read at compile time and ’configures’ the flash movie.

For my plugin I changed this file to look like this.

http://ianlawrence.info/random-stuff/mobile-linux-image-creation-made-easy

http://moblin.org/

http://www.freedesktop.org/wiki/Software/GeoClue/


71 / 78

....snip

<app id="8" title="TBD Camera" desc="Camera App" icon="icons/camera.png" path="" />

<app id="9" title="Control Panel" desc="Control Panel" icon="icons/controlpanel.png" path ←↩="/usr/bin/controlpanel" />

<app id="10" title="Location Services" desc="" icon="icons/geoclue.png" path="/usr/bin/ ←↩geoclue" />

...snip

We are telling Flash to make an XML socket call and execute the file /usr/bin/geoclue. We will to create this file later on Put youapplication icon inside the ’icons’ folder and run:

vern@N800-hacker:~/flash/mobile-basic-flash$ ./autogen.sh

this ’loads’ the conf.xml into the flash movie then we need to copy the movie, the conf.xml file and the icon to the correct placeinside moblin

vern@N800-hacker:~/flash/mobile-basic-flash/content$ sudo cp conf.xml flash_home.swf /home/ ←↩vern/moblin/image/targets/target/fs/usr/share/mobile-basic-flash/

Password:

vern@N800-hacker:~/flash/mobile-basic-flash/content/icons$ sudo cp geoclue.png /home/vern/ ←↩moblin/image/targets/target/fs/usr/share/mobile-basic-flash/icons/

The UI now looks like this with our

Location Services icon:


72 / 78

7.1.2 The GeoClue backend.

GeoClue is a D-Bus API and library and it uses several backends to get geographic data from various sources and abstracts thedifferences of those data sources as much as possible, so applications can just ask for e.g. current coordinates and not care wherethe coordinates come from (current options for coordinates are GPS and hostip.info). The following APIs (and backend types)are supported or planned:

* Positioning

* Routing

* Geocoding

* Map

* Track Logs

For this example we will use a backend called hostip.info which returns a city based on your IP.

(need git-core)

vern@N800-hacker:~$ git clone git://anongit.freedesktop.org/git/geoclue

vern@N800-hacker:~$ cd geoclue

vern@N800-hacker:~/geoclue$ sudo ./autogen.sh

configure: error: Install gpsd Debian package or its source-code equivalent:

a quick apt-cache search reveals:


73 / 78

gpsd - GPS (Global Positioning System) daemon

so:

vern@N800-hacker:~/geoclue$ sudo apt-get install gpsd

try again:


checking for HTTPXML... configure: error: Package requirements (libsoup-2.2 libxml-2.0) ←↩were not met:

No package ’libsoup-2.2’ found

Consider adjusting the PKG_CONFIG_PATH environment variable if you

installed software in a non-standard prefix.

Alternatively, you may set the environment variables HTTPXML_CFLAGS

and HTTPXML_LIBS to avoid the need to call pkg-config.

See the pkg-config man page for more details.

It seems like we are missing some

development libraries:

vern@N800-hacker:~/pyphantom_b4Brazil/geoclue$ sudo apt-get install libglib2.0-dev libgtk2 ←↩.0-dev libsoup2.2-dev libgconf2-dev libxml++2.6c2a

and now it works:


vern@N800-hacker:~/geoclue$ sudo make

vern@N800-hacker:~/geoclue$ sudo make install


74 / 78

Fire up pyphantom the hildon desktop

IDE and create the following Home plugin:

import gtk

import pygtk

import hildondesktop

import dbus

import os

class GeocluePlugin(hildondesktop.StatusbarItem):

def __init__(self):

hildondesktop.StatusbarItem.__init__(self)

# Start with getting position from GeoClue

bus = dbus.SessionBus()

# TODO: Get the GeoClue interface to use from /schemas/apps/geoclue/position/ ←↩defaultpath

# and /schemas/apps/geoclue/position/defaultserviceGConf keys

proxy_obj = bus.get_object(’org.foinse_project.geoclue.position.hostip’, ’/org/ ←↩foinse_project/geoclue/position/hostip’)

geoclue_iface = dbus.Interface(proxy_obj, ’org.foinse_project.geoclue.position’)

# Get the coordinates from the service

coordinates = geoclue_iface.current_position()

#location = geoclue_iface.current_location()


75 / 78

# We can also use hardcoded

#coordinates[0] = 60.158806494564

#coordinates[1] = 24.9426341056824

print "According to GeoClue you are in %s %s." % (coordinates[0], coordinates[1])

def hd_plugin_get_objects():

plugin = GeocluePlugin()

return [plugin]]

and this will show user coordinates

in the Debug I/O (you may need to try a few times as there is some parsing bug in the hostip API):

Inside the plugin ’src’ folder there will be 2 files: geoclue.py and geoclue.desktop and we need to copy these to the correct areasinside our image.

vern@N800-hacker:~/geoclue/src$ sudo cp geoclue.py /home/vern/moblin/image/targets/target/ ←↩fs/usr/lib/hildon-desktop/

vern@N800-hacker:~/geoclue/src$ sudo cp geoclue.desktop /home/vern/moblin/image/targets/ ←↩target/fs/usr/share/applications/hildon-marquee

in the file:

/etc/hildon-desktop/marquee.conf

add the following line:

/usr/share/applications/hildon-marquee/geoclue.desktop

Now we need to create our /usr/bin/geoclue

file:


76 / 78

#!/bin/sh

cd /usr/lib/hildon-desktop/

python geoclue.py

and then do:

chmod +x geoclue.py

we then need to start moblin and choose our application in the UI. It executes and presents the user with some info about theircurrent location.


77 / 78

Chapter 8

Theming and Customization of UME

8.1 Overview

The hildon user interface that’s powering Ubuntu Mobile is themable (skinable) and the look can be customized to a great extent.An artist can develop his own skin and ship it in a stand-alone package for others to install and use. Currently a pixmap-basedtheming is used for performance reasons. Pixmap-based theming means that widget looks are being assembled from individualbitmap images used in different configurations.

Hildon theming overview

http://live.gnome.org/Hildon/ThemingOverview


78 / 78

Chapter 9

API References

9.1 D-Bus API

D-Bus is a system for interprocess communication (IPC).

D-Bus API

9.2 GTK API

GTK (GIMP Toolkit) is a library for creating graphical user interfaces

GTK API

Glib API

9.3 Hildon API

Hildon application framework introduces a new desktop for handheld devices.

Hildon FM API

Hildon Libs API

API documentation for Hildon Status bar, Home Applets and Navigator

API documentation for Hildon Control Panel

API documentation for python bindings for Hildon

API documentation for Python bindings for Libosso

9.4 Gnome Developer Documentation

Gnome Libraries

http://dbus.freedesktop.org/doc/dbus/api/html/index.html

http://developer.gnome.org/doc/API/gtk/index.html

https://stage.maemo.org/svn/maemo/projects/haf/doc/api/glib/index.html

http://test.maemo.org/platform/docs/api-bora/hildon-docs/fm-html/index.html

http://test.maemo.org/platform/docs/api-bora/hildon-docs/hildon-libs/index.html

http://test.maemo.org/platform/docs/api-bora/maemo-af-desktop-api/dirs.html

http://test.maemo.org/platform/docs/api-bora/hildon-docs/hildon-control-panel/files.html

http://test.maemo.org/platform/docs/pymaemo/python_hildon_widgets_api.html

http://test.maemo.org/platform/docs/pymaemo/pyosso_context.html

http://lgo.0d.be/developers/

ubuntu mobile guide - the world's most popular free os | ubuntu

Documents