OpenMokoFramework/es

From Openmoko

Jump to: navigation, search

OpenMokoFramework is a set of libraries defining the common look and feel of OpenMoko applications.

Contents

Overview

This sections shows an overview about the OpenMoko framework libraries and their dependencies.

Image:Openmokoframework.png

A printer-friendly version (PDF) can be found here.

Contents

This section describes the mapping of OpenMoko libraries to functionality.

libmokocore

Provides functionality:

  • Sending messages between OpenMoko applications
  • Encapsulating the dbus device API
    • switching devices on/off
    • getting/setting brightness/volume/signal strength
    • Example: Dialer application sends a dbus-signal to Contacts application when a call with an Mr.Unknown has finished.
  • Reading / Writing persistent application data
    • Example: Configuring preferences
    • Example: Saving the state of open/collapsed Preview Widgets when leaving the Contacts application.

Uses:

  • dbus for application-to-application signalling
  • Gconf for storing application session data and preferences.

API:

TODO: define API (See: To-Do List)


libmokonet

Provides functionality:

  • High-Level Connection Queries
    • Example: Which peers can we send a file to [no matter whether it's via Internet or Bluetooth]?
    • Example: Are we in a defined environmental region? [i.e. our office]
    • Question: does OpenMoko support multiple concurrent network paths. E.g. my chat application connects via GPRS, but the browser (or some other bulk transferring app) connects via bluetooth? The point here is, that even with bluetooth Internet connectivity available, it might be better to connect to the Internet via GPRS, to avoid breaking longrunning TCP connections? But, we should give the user that choice, in case that GPRS is very expensive (some countries, some plans) whereas Internet access is flat rate.

Uses:

API:

TODO: define API (See: To-Do List)


libmokopim

Provides functionality:

  • A convenient high-level API to query PIM (Personal Information Management) Data
    • Example: Give List of Contacts from Addressbook
    • Example: Which Contacts are in Group 'foo'
    • Example: Give Connection History for certain Contact

Uses:

TODO: define API (See: To-Do List)


libmokoui

Provides:

  • GTK+ derived high-level widgets for the common OpenMoko look & feel
    • Example: MenuBar, ToolBar
  • API for checking X11 InputMethod status
    • Example: Which type of Input Method was last selected?
    • Example: Is the Input Method currently visible or not?
  • API for triggering UI events (i.e. sounds, vibration, ...)
    • Example: Play Alarm Tone
    • Example: Vibrate for 10 seconds w/ Pattern *--*--*--*

Uses:

Contents:


Application & Windows

  • MokoApplication -- Base Class for OpenMoko Applications
  • MokoWindow -- Base Class for OpenMoko Appplication Windows
  • MokoPanedWindow -- Base Class for 4-part stylus applications Main Window
  • MokoFingerWindow -- Base Class for finger applications Main Window

Containers

  • MokoFixed -- Class for widgets with fixed background pixmap + widgets on top (analogue to GtkFixed)
  • MokoAlignment -- Class for widgets with fixed background pixmap + aligned widget on top (analogue to GtkAlignment)

Preview Widgets

Field Widgets

  • MokoFieldWidget -- Implements the OpenMoko field widget
TODO: Decide whether one class implements multiple types of field widget or whether we want to have multiple classes (See: To-Do List)


Bar Widgets

List Widgets

Special Widgets

  • MokoFingerWheel -- Implements the Finger Scrolling Widget residing in the bottom left corner of a MokoFingerWindow
  • MokoFingerToolbar -- Implements the Finger Toolbar Widget residing in the bottom right corner of a MokoFingerWindow

Common Dialogs

TODO: Define the API and full inheritance tree (See: To-Do List)


Implementation Plan

This section describes the process of implementing the OpenMoko core libraries.

The basic idea is that the functionality and the API of the OpenMoko libraries are application-driven, which means an API is added the very moment it benefits more than just one application.

It also means that we can develop the OpenMoko framework in parallel to the OpenMoko core applications. For instance, the major user for the Preview Widgets is the Contacts application, however these widgets will surely be useful in the Calendar application as well.

There are even components like the Menubar which will be a part of almost every OpenMoko stylus application.

In short, I plan to lay out a rough plan of the API until 1st week of October and then Shanghai Lab will start with developing applications while I am supporting the refactoring of reusable functionality from the applications into the library.

Please remember that the Open Source community is very picky when it comes to libraries. If we want the casual user to adopt our phone, then it is important that we have an excellent usability and look & feel, however if we want the open source community to adopt our platform, then our application framework needs to be done right:

  • clear
  • concise
  • consistent
  • as simple as possible
  • as reusable as possible


Languages: 

English •  Русский •  Deutsch •  Svenska •  简体中文 •  Polski •  Nederlands •  Eesti •  한국어 •  Français •  Español •  Română •  Български •  Ελληνικά •  Slovensky •  Italiano •  عربي •  Česky •  日本語 •  Português •  繁體中文 • 

Retrieved from "http://wiki.openmoko.org/wiki/OpenMokoFramework/es"
Personal tools