View source for Wish List

From Openmoko

Jump to: navigation, search

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Administrators.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

Templates used on this page:

Return to Wish List.

Personal tools

This article is a place to collect various thoughts about the future of the OpenMoko software platform.

Development Related

Painless SDK installation & Setup

Our goal should be a completely painless setup for somebody wanting to develop using OpenMoko

  • one command for installation (apt-get install openmoko)
  • one command to start Xnest (openmoko-xephyr?)
  • one command to start an i386 shell (openmoko-386-shell)
  • one command to start an armel shell (openmoko-armel-shell)

No extra configuration required (allowed ;)

IDE Plugins

People like to see plugins for

  • Anjuta
  • Eclipse
  • Kdevelop
  • XCode
  • Microsoft Visual Studio 2005

UI Designer

Glade code generation is deprectated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also the relevant bug entry

  • Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

Community Support Related

Infrastructure for developers w/

  • one bugzilla for all projects (makes moving bugs forth and backwards between projects _very_ easy)
  • one mailinglist for project

Platform Related

Community Images

In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

Software Related: Additional Features

Text Messaging

There are many useful options that now can be used to full capacity:

  • In GSM networks so-called acknowledge-sms are sent back to the sms's dispatcher in order to indicate that the primal sms was recieved(as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and recieve delivery status message' and 'send and notify(e.g. ring) when delivery succeeded'.
  • You could be able to set up messages that are sent at a certain time/date
  • Send binary sms. Could be used to feign wap pushs. [1] See:
  • SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
  • Implement a script that de-abbreaviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [6])
    • Implement a script that abbreaviates :-)
  • Dutton Speedwords. Maybe helpful?
  • GPS fun.
  • Input help(which as a matter of fact does not belong to text messaging but input in general): I guess there won't be any T9 as it's not open. Alternatives? (Let's make the worlds most convenient input method for mobiles :-) See:

Multiboot Support

I'd like to see U-Boot being enhanced to support a boot menu that allows to boot a complete image from the MMC. This way we have a simple way for part-time developers (aka people actually _using_ their phone or people not having a seperate phone for development) to experiment with new OpenMoko releases or custom images.

Printing Support

It would be really neat to be able to print over either bluetooth or USB. I can imagine wanting to print:

  • Notes
  • Maps
  • Email
  • Calendars
  • ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

  1. GTK+'s printing support
  2. Making cups run on a really small system
NOTE: GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.

There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:

PalmOS Emulator

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally millions of PalmOS apps.

Special Profiles

After reading something about too much features in mobile phones I thought about the following. It would be nice to have the possibility to choose from several profiles when starting the phone the first time. Every user profile is defined for special kinds of user behaviour. Let me define some example profiles:

  • Beginner: Only basic functionality like, telephone and sms
  • Advanced: included "Beginner" profile and let me say e-mail, pim functions
  • Geek: every functionality you can get
  • Granny: a minimum of functionality

etc. In addition the user should be able to create his own profiles. The advantage is that the user gets not frustrated by thousands of menus. What do you think about such a feature?

GPS Assisted Bluetooth Management

Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.

A Bluetooth device is configured for automatic reacquisition based on the following profiles:

  • Manual - only when Bluetooth is on
  • Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.
  • Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.

Each target device is configured as follows:

  • Automatic acquisition at last known location: enable/disable
  • Automatic acquisition at these locations: list of nickname + coordinates + range

Non-mobile devices

Examples devices include: computers

The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.

Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.

Mobile devices

Example devices include: automobiles

Mobile devices are configured to have two types of locations:

  1. Last known location
  2. Non-mobile locations (homes)
Last known location

A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.

Non-mobile locations (homes)

As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.

Running multiple application

It would be a big step to have the ability to run multiple programs like downloading emails and browsing the net or using a calculator and writing a text message and being able to swap between them quickly and formlessly.

Software Related: Language Bindings

Python Bindings

Python bindings seem to be a commonly requested feature.

User:Mickey says, "They are kind of usable on the Nokia 770, but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

C++ Bindings

There is a whole skilled C++ community coming from the Qtopia and Opie projects. If we would consider basing OpenMoko C++ Bindings on Gtkmm, then we could drag these guys in.

Perl Bindings

Another popular language

Software Related: Foreign Widget Set Bindings

Qt Integration

The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

Maemo Integration

The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

wxWidgets Integration

wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for GSoC 2007

SDL Integration

SDL is _the_ game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.