Openmoko - User contributions [en]

Wishlist/Extension Framework

2007-08-18T19:59:14Z

Jgm:

{{Wishlist}}

The extension framework is an application for handling extensions to the core OpenMoko functionality. It is designed to allow developers to build extensions that can affect the core functionality of the device without requiring extensive knowledge of, or even access to, the code that exists to carry out core functionality. It also allows for multiple extensions to affect the same core functionality, handling ordering and chaining of the extensions to ensure consistent results.

The rationale behind such a framework is to allow developers to create piecemeal functionality rather than having to alter or extend a large existing piece of code. Taking an outgoing call as an example there are a number of things that may be required around it, such as:

* only allow certain numbers to be dialed at certain times of the day
* only allow numbers in the addressbook to be dialed at certain times of the day, or a maximum number of times per day
* reroute calls using calling cards, low-cost numbers or similar methods
* reroute calls through a VOIP gateway
* mask caller ID depending on if the number called is in the addressbook
* update twitter with the fact that you are attempting to call someone, perhaps with details of the number (or name if they are in the addressbook)

Some of the above features are generally useful and would be expected to be made available in any complete 'phone implementation. Others are very unlikely to make it in to a core codebase. But all of them may be useful in a given situation, so for openmoko to be as flexible as possible these all need to be possible. As such, an extension framework that puts each user in control of what the 'phone will do in any given situation is the only way of providing both the required functionality as well as the core stability and speed that is required.

The extension framework consists of a number of entities, namely the extension manager, the extension configuration GUI and the extension handler. Each of these are discussed in more detail below.

=== Scope ===

The extension framework is initially aimed at providing a way of extending the core functionality of an OpenMoko device, and even more specifically of extending the abilities of the device in the area of making and receiving 'phone calls. However, there will be nothing in the design that limits it to handling just this area and indeed the design will allow for any type of extension given the correct method calls within the core code.

Note that the extension framework is not designed to manage GUI updating and interaction, although it is possible it could be used for this it is not designed to be a UI event bus and no consideration is given to this type of fucntionality.

=== Components ===

The extension framework will consist of three main components which will manage various aspects of managing and using the extensions. These components may or may not be separate processes, although there is a reliability advantage to having the handler separate from the other components it introduces additional complexity. The names and functions of the three components are:

* The extension manager handles registration and activation of extensions as well as providing them a clean interface to store preference and configuration information.
* The extension handler carries out the work of receiving method calls to the extension manager, passing them to the relevant extensions and providing a final reply back to the calling method.
* The extension configuration GUI provides end users with the ability to configure each extension along with altering preferences and enabling/disabling specific features of each extension.

A final component of the extension framework will be a C library will provide extension developers with helper functions to achieve common tasks. This should allow extensions to be developed as quickly and efficiently as possible.

=== Example of a Method Call with the Framework Handler ===

For the following advantage we assume that gsmd is enabled for the extension framework. A pictorial representation of the method call is shown below.

[[Image:Extensionframework_method.png]]

#As gsmd gets ready to make a 'phone call it reaches the stage where it has set up all of its parameters and is about to start the process of making a call. It is at this point that the method call to the extension framework is made, by calling outgoingcall() with the following parameters:
#* number: a string that contains the number that gsmd was planning to dial (populated with the number passed in to the function)
#* sendid: whether or not to send caller ID (as per system or user default)
# When the extension handler receives this method it carries out a lookup of the extensions that are currently registered and active and puts together a list of which extensions should be contacted in which order. In this case two extensions are returned as being interested in the information, along with the order in which they should be approached.
# The first relevant extension is contacted and carries out its work
# The first relevant extension returns the following values:
#* number: a string that contains the new number to dial (which may be the same as the input number to dial)
#* sendid: whether or not to send caller ID
#* status: a numeric result of the extension's work, which may be one of the following generic types:
#** Continue: continue with the existing operation
#** Handoff: the existing operation has been handed off to another application so no further action required
#** Error: an error has occurred with this item so further processing should be aborted
#* statusreason: additional text that can be displayed to explain the status result if required
# The second relevant extension is contacted and carries out its work. Note that the parameters sent to this module include the updated number and sendid from the first relevant extension
# The second relevant extension returns the values as per the first extension
# The extension handler returns the final results in the reply to the calling method. At this stage gsmd should use the parameters returned rather than those it had prior to the call for the purposes of dialing a number and sending/not sending caller ID. It should also confirm that it is authorized to continue with the operation, and if not abort appropriately

=== Example of an Extension Registration ===

Extensions must be registered with the extension manager so that the extension handler is aware of them and can incorporate them in to extension requests. A pictorial representation of the registration process is shown below.

[[Image:Extensionframework_registration.png]]

# An extension sends a registration method to the extension manager. The method contains the following information:
#* extension. This is the full name of the method we wish to extend, for example org.openmoko.extension.Gsmd.OutgoingCall
#* name. This is the name of the object that is carrying out the extension, for example net.devzero.SampleExtension
#* path. This is the path to the object that is carrying out the extension, for example /net/devzero/SampleExtension
#* interface. This is the interface for the object that is carrying out the extension, for example net.devzero.SampleExtension
#* method. This is the method on the object that is carrying out the extension, for example GsmdOutgoingCall
# The extension manager logs the information in a central configuration store where it can be accesed by the extension handler
# The extension manager returns the call

Once an extension has registered a method then it will be called by the extension handler whenever required.

Unregistering an extension uses exactly the same methodology except that the method is Unregister rather than Register, all parameters stay the same.

=== Use Cases ===

There are a number of [[Wish List]] entries for which the extension framework could be used, these are as follows:
#[[Wish List#Mask ID based on dialed numbers|Mask outgoing caller ID based in dialed number]]
#[[Wish List#Use calling cards and similar routing techniques for lower-cost calling|Use calling cards and similar routing techniques for lower-cost calling]]
#[[Wish List#Outgoing black/white lists|Outgoing black/white lists]]
#[[Wish List#Time-based blocking/unblocking of calls|Time-based blocking/unblocking of calls]]

MokoMakefile

2007-08-18T16:18:47Z

Jgm: /* Developing with MokoMakefile */

==MokoMakefile==
MokoMakefile is a fully automated way of setting up an OpenMoko development environment. It is an invaluable tool for getting new developers up and running with a build environment which is configured the same as all the other existing developers. It brings the same repeatability to build environment creation and maintenance as that which OpenEmbedded brings to the main task of actually building embedded software distributions.

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed. Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

MokoMakefile is developed by [[User:RodWhitby|Rod Whitby]] - it is not an official product of OpenMoko (although I would be happy for them to pick it up and use it internally). If there is any discrepancy between the [[Building_OpenMoko_from_scratch|official OpenMoko build instructions]], and the operation of the MokoMakefile, then you should consider the official instructions to be correct.

There is an alpha version of the MokoMakefile available at http://svn.nslu2-linux.org/svnroot/mokomakefile/branches/OM-2007.2/Makefile which builds OM-2007.2 images. You should only try this if you are an experienced MokoMakefile user. If not, then please wait for the official OM-2007.2 release to be announced.
You have to install help2man to run make openmoko-devel-image.

=== Before you begin ===
'''Check that your /bin/sh (ls -l /bin/sh) is not linked to dash rather than bash.''' Using dash will cause you pain. This is true for a standard install of Ubuntu 7.04 (at least when installing from Live CD). If your /bin/sh points to /bin/dash, correct it with (as root):
ln -sf /bin/bash /bin/sh

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

If you have previously built with dash as your sh shell then your perl compile is probably broken. One symptom is that the build will error and whine about an 'Unterminated quote string'. Another symptom is a message that says 'You haven't done a "make depend" yet!' If you get these then you need to:
make clean-package-perl
make clean-package-perl-native
and rebuild.

If all else fails then just rm -rf the perl work dir and the perl stamps. Here's an i686 host example:
rm -rf build/tmp/work/i686-linux/perl-native-5.8.7-r3
rm -f build/tmp/stamps/i686-linux/perl*

As of r99, MokoMakefile has patches which should make it build correctly with dash.

You need to get mtn and svn for make.
sudo apt-get install subversion monotone

=== Installation ===
Here are the steps to use it:

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

This will set up the recommended directory structure as described in [[Building OpenMoko from scratch]], will download all the required software (from the right places with the right versions), and will immediately start building an image.

Once you have done this, you can choose to continue using the MokoMakefile to initiate your subsequent builds, or you can go into the build directory and run bitbake commands manually. The choice is yours.

===Updating the environment===
For easy maintenance of your build environment the following commands are available.

1 - To update the MokoMakefile to the latest version:
make update-makefile

2 - To update the OpenMoko repository checkout and the MokoMakefile patches to the latest version:
make update

3 - To make sure that any recent changes to the build directory structure have been applied:
make setup

A quick way to rebuild a new image with the latest updates:
make update-makefile && make update setup openmoko-devel-image

===Reporting Problems===

First, make sure that the problem is reproducible after running

make update-makefile && make update && make setup

then running

make clean-package-<foo>

(where you replace <foo> with the name of the package which is failing)

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (including the update and setup steps) three times, then feel free to report it to rwhitby in #openmoko on [http://wiki.openmoko.org/wiki/Development_resources#IRC IRC].

===Work-arounds===

Work-arounds for temporary or isolated problems should be added to the [[Talk:MokoMakefile|Discussion page]] which is associated with this page. As they are fixed, they will be removed from that page.

===Tips===
*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. ~/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly.

*If you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/''username''/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in ~/moko:
# mtn --db OE.mtn db migrate

*If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package>
after that your build might just work again.

*For people with multiple CPU's (or dual-core ones) this small patch might be useful to build things faster.
Edit the local.conf and add the following lines:
PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Change the PARALLEL_MAKE and BB_NUMBER_THREADS values to something that suits better if it chokes your machine.

*For amd64 host users you need the patch from http://bugs.openembedded.org/show_bug.cgi?id=1765 to build db3-native

===QEMU===
The MokoMakefile now has support for automatically building, flashing, and running [[OpenMoko under QEMU|the new Neo1973 emulator]] (which is based on QEMU).

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev in Ubuntu .704')
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

“'''make qemu'''” will build qemu-neo1973, download the latest official OpenMoko images, flash the images into the virtual NAND flash, create an empty virtual SD card, and run the emulator (you still need to install the makefile as mentioned above, however).

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

Make sure you have the “lynx” and “netpbm” packages installed on your build host first.

You're also invited to read more about how to run [[OpenMoko under QEMU]] in the article dedicated to this subject.

===Developing with MokoMakefile===

{{note|If using MokoMakefile with OM2007.2 then references to $OMDIR/openmoko should be replaced with $OMDIR/openembedded. Also references to tmp/work/armv4t-linux should be replaced with tmp/work/fic-gta01-angstrom-linux-gnueabi}}

For the following explanations $OMDIR is the directory where there Makefile puts all the stuff.

To make in-tree changes and have them built and used by qemu:

cd $OMDIR/openmoko
quilt new descriptive-patch-name.patch
quilt add trunk/src/name-of-file-to-change # do this for every file you are about to modify
...make the changes...
quilt refresh # this creates a file in $OMDIR/patches/openmoko-HEAD/ and updates the quilt series file there

Note: Do '''NOT''' use absolute paths as this confuses quilt and will get you a diff of the file against /dev/null!

To build the changes and have them used by qemu:

make build-qemu
make flash-qemu-local
make run-qemu

If you want to modify applications instead of the openmoko toolchain, this is what you have to do (example: openmoko-messages):

cd $OMDIR/build
. ../setup-env
bitbake -c unpack openmoko-messages
cd ../build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
...make the changes...
cd -
bitbake openmoko-messages

Then continue with MokoMakefile usage.

If you want to add an application to your openmoko distribution, do this:
All file edits should be done using quilt as described above. That way a patch can easily be submitted to the openmoko project.
First, create a directory that will correspond to your package and edit a '''.bb''' file in there:
cd $OMDIR/openmoko/
quilt new mycoolpackage.patch
mkdir trunk/oe/packages/mycoolpackage
quilt add trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb
quilt edit trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb

The file should have the following content:
DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

SRC_URI = "http://www.example.com/download/mycoolpackage-1.tar.gz"

Explanation:
* DESCRIPTION - Just a short text explaining the package
* SECTION - I have no clue, but I'll use username/mycoolpackage for now
* PV - Package Version
* inherit autotools - The package can be compiled by './configure && make && make install' so we tell MokoMakefile to do it this way.
* SRC_URI = ... - This is the download location of the package source. It's imperative that the tar.gz contains a directory called '''packagename-packageversion''' (in this case: mycoolpackage-1) so that MokoMakefile can find it automatically or the build will fail.

This is not all. We also need to tell MokoMakfile that it needs to build and include the package in the image. To do this, do
$OMDIR/openmoko# quilt edit trunk/oe/packages/tasks/task-openmoko.bb
Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run
quilt refresh
cd ..
make update all

And if everything's alright you should now have an OpenMoko image to flash to your phone or run in qemu as described above.

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/Building_a_hello_world_application Hello World!] tutorial available too.

===Testimonials===
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", "MokoMakefile rocks!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

Project page:
http://mokomakefile.projects.openmoko.org/

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-08-18T11:26:08Z

Jgm:

==MokoMakefile==
MokoMakefile is a fully automated way of setting up an OpenMoko development environment. It is an invaluable tool for getting new developers up and running with a build environment which is configured the same as all the other existing developers. It brings the same repeatability to build environment creation and maintenance as that which OpenEmbedded brings to the main task of actually building embedded software distributions.

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed. Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

MokoMakefile is developed by [[User:RodWhitby|Rod Whitby]] - it is not an official product of OpenMoko (although I would be happy for them to pick it up and use it internally). If there is any discrepancy between the [[Building_OpenMoko_from_scratch|official OpenMoko build instructions]], and the operation of the MokoMakefile, then you should consider the official instructions to be correct.

There is an alpha version of the MokoMakefile available at http://svn.nslu2-linux.org/svnroot/mokomakefile/branches/OM-2007.2/Makefile which builds OM-2007.2 images. You should only try this if you are an experienced MokoMakefile user. If not, then please wait for the official OM-2007.2 release to be announced.
You have to install help2man to run make openmoko-devel-image.

=== Before you begin ===
'''Check that your /bin/sh (ls -l /bin/sh) is not linked to dash rather than bash.''' Using dash will cause you pain. This is true for a standard install of Ubuntu 7.04 (at least when installing from Live CD). If your /bin/sh points to /bin/dash, correct it with (as root):
ln -sf /bin/bash /bin/sh

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

If you have previously built with dash as your sh shell then your perl compile is probably broken. One symptom is that the build will error and whine about an 'Unterminated quote string'. Another symptom is a message that says 'You haven't done a "make depend" yet!' If you get these then you need to:
make clean-package-perl
make clean-package-perl-native
and rebuild.

If all else fails then just rm -rf the perl work dir and the perl stamps. Here's an i686 host example:
rm -rf build/tmp/work/i686-linux/perl-native-5.8.7-r3
rm -f build/tmp/stamps/i686-linux/perl*

As of r99, MokoMakefile has patches which should make it build correctly with dash.

You need to get mtn and svn for make.
sudo apt-get install subversion monotone

=== Installation ===
Here are the steps to use it:

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

This will set up the recommended directory structure as described in [[Building OpenMoko from scratch]], will download all the required software (from the right places with the right versions), and will immediately start building an image.

Once you have done this, you can choose to continue using the MokoMakefile to initiate your subsequent builds, or you can go into the build directory and run bitbake commands manually. The choice is yours.

===Updating the environment===
For easy maintenance of your build environment the following commands are available.

1 - To update the MokoMakefile to the latest version:
make update-makefile

2 - To update the OpenMoko repository checkout and the MokoMakefile patches to the latest version:
make update

3 - To make sure that any recent changes to the build directory structure have been applied:
make setup

A quick way to rebuild a new image with the latest updates:
make update-makefile && make update setup openmoko-devel-image

===Reporting Problems===

First, make sure that the problem is reproducible after running

make update-makefile && make update && make setup

then running

make clean-package-<foo>

(where you replace <foo> with the name of the package which is failing)

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (including the update and setup steps) three times, then feel free to report it to rwhitby in #openmoko on [http://wiki.openmoko.org/wiki/Development_resources#IRC IRC].

===Work-arounds===

Work-arounds for temporary or isolated problems should be added to the [[Talk:MokoMakefile|Discussion page]] which is associated with this page. As they are fixed, they will be removed from that page.

===Tips===
*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. ~/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly.

*If you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/''username''/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in ~/moko:
# mtn --db OE.mtn db migrate

*If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package>
after that your build might just work again.

*For people with multiple CPU's (or dual-core ones) this small patch might be useful to build things faster.
Edit the local.conf and add the following lines:
PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Change the PARALLEL_MAKE and BB_NUMBER_THREADS values to something that suits better if it chokes your machine.

*For amd64 host users you need the patch from http://bugs.openembedded.org/show_bug.cgi?id=1765 to build db3-native

===QEMU===
The MokoMakefile now has support for automatically building, flashing, and running [[OpenMoko under QEMU|the new Neo1973 emulator]] (which is based on QEMU).

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev in Ubuntu .704')
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

“'''make qemu'''” will build qemu-neo1973, download the latest official OpenMoko images, flash the images into the virtual NAND flash, create an empty virtual SD card, and run the emulator (you still need to install the makefile as mentioned above, however).

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

Make sure you have the “lynx” and “netpbm” packages installed on your build host first.

You're also invited to read more about how to run [[OpenMoko under QEMU]] in the article dedicated to this subject.

===Developing with MokoMakefile===

{{note|If using MokoMakefile with OM2007.2 then references to $OMDIR/openmoko should be replaced with $OMDIR/openembedded}}

For the following explanations $OMDIR is the directory where there Makefile puts all the stuff.

To make in-tree changes and have them built and used by qemu:

cd $OMDIR/openmoko
quilt new descriptive-patch-name.patch
quilt add trunk/src/name-of-file-to-change # do this for every file you are about to modify
...make the changes...
quilt refresh # this creates a file in $OMDIR/patches/openmoko-HEAD/ and updates the quilt series file there

Note: Do '''NOT''' use absolute paths as this confuses quilt and will get you a diff of the file against /dev/null!

To build the changes and have them used by qemu:

make build-qemu
make flash-qemu-local
make run-qemu

If you want to modify applications instead of the openmoko toolchain, this is what you have to do (example: openmoko-messages):

cd $OMDIR/build
. ../setup-env
bitbake -c unpack openmoko-messages
cd ../build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
...make the changes...
cd -
bitbake openmoko-messages

Then continue with MokoMakefile usage.

If you want to add an application to your openmoko distribution, do this:
All file edits should be done using quilt as described above. That way a patch can easily be submitted to the openmoko project.
First, create a directory that will correspond to your package and edit a '''.bb''' file in there:
cd $OMDIR/openmoko/
quilt new mycoolpackage.patch
mkdir trunk/oe/packages/mycoolpackage
quilt add trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb
quilt edit trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb

The file should have the following content:
DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

SRC_URI = "http://www.example.com/download/mycoolpackage-1.tar.gz"

Explanation:
* DESCRIPTION - Just a short text explaining the package
* SECTION - I have no clue, but I'll use username/mycoolpackage for now
* PV - Package Version
* inherit autotools - The package can be compiled by './configure && make && make install' so we tell MokoMakefile to do it this way.
* SRC_URI = ... - This is the download location of the package source. It's imperative that the tar.gz contains a directory called '''packagename-packageversion''' (in this case: mycoolpackage-1) so that MokoMakefile can find it automatically or the build will fail.

This is not all. We also need to tell MokoMakfile that it needs to build and include the package in the image. To do this, do
$OMDIR/openmoko# quilt edit trunk/oe/packages/tasks/task-openmoko.bb
Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run
quilt refresh
cd ..
make update all

And if everything's alright you should now have an OpenMoko image to flash to your phone or run in qemu as described above.

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/Building_a_hello_world_application Hello World!] tutorial available too.

===Testimonials===
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", "MokoMakefile rocks!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

Project page:
http://mokomakefile.projects.openmoko.org/

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

Wishlist/Extension Framework

2007-07-27T00:06:15Z

Jgm:

{{Wishlist}}

The extension framework is an application for handling extensions to the core OpenMoko functionality. It is designed to allow developers to build extensions that can affect the core functionality of the device without requiring extensive knowledge of, or even access to, the code that exists to carry out core functionality. It also allows for multiple extensions to affect the same core functionality, handling ordering and chaining of the extensions to ensure consistent results.

The rationale behind such a framework is to allow developers to create piecemeal functionality rather than having to alter or extend a large existing piece of code. Taking an outgoing call as an example there are a number of things that may be required around it, such as:

* only allow certain numbers to be dialed at certain times of the day
* only allow numbers in the addressbook to be dialed at certain times of the day, or a maximum number of times per day
* reroute calls using calling cards, low-cost numbers or similar methods
* reroute calls through a VOIP gateway
* mask caller ID depending on if the number called is in the addressbook
* update twitter with the fact that you are attempting to call someone, perhaps with details of the number (or name if they are in the addressbook)

Some of the above features are generally useful and would be expected to be made available in any complete 'phone implementation. Others are very unlikely to make it in to a core codebase. But all of them may be useful in a given situation, so for openmoko to be as flexible as possible these all need to be possible. As such, an extension framework that puts each user in control of what the 'phone will do in any given situation is the only way of providing both the required functionality as well as the core stability and speed that is required.

The extension framework consists of a number of entities, namely the extension manager, the extension configuration GUI and the extension handler. Each of these are discussed in more detail below.

=== Scope ===

The extension framework is initially aimed at providing a way of extending the core functionality of an OpenMoko device, and even more specifically of extending the abilities of the device in the area of making and receiving 'phone calls. However, there will be nothing in the design that limits it to handling just this area and indeed the design will allow for any type of extension given the correct method calls within the core code.

Note that the extension framework is not designed to manage GUI updating and interaction, although it is possible it could be used for this it is not designed to be a UI event bus and no consideration is given to this type of fucntionality.

=== Components ===

The extension framework will consist of three main components which will manage various aspects of managing and using the extensions. These components may or may not be separate processes, although there is a reliability advantage to having the handler separate from the other components it introduces additional complexity. The names and functions of the three components are:

* The extension manager handles registration and activation of extensions as well as providing them a clean interface to store preference and configuration information.
* The extension handler carries out the work of receiving method calls to the extension manager, passing them to the relevant extensions and providing a final reply back to the calling method.
* The extension configuration GUI provides end users with the ability to configure each extension along with altering preferences and enabling/disabling specific features of each extension.

A final component of the extension framework will be a C library will provide extension developers with helper functions to achieve common tasks. This should allow extensions to be developed as quickly and efficiently as possible.

=== Example of a Method Call with the Framework Handler ===

For the following advantage we assume that gsmd is enabled for the extension framework. A pictorial representation of the method call is shown below.

[[Image:Extensionframework_method.png]]

#As gsmd gets ready to make a 'phone call it reaches the stage where it has set up all of its parameters and is about to start the process of making a call. It is at this point that the method call to the extension framework is made, by calling outgoingcall() with the following parameters:
#* number: a string that contains the number that gsmd was planning to dial (populated with the number passed in to the function)
#* sendid: whether or not to send caller ID (as per system or user default)
# When the extension handler receives this method it carries out a lookup of the extensions that are currently registered and active and puts together a list of which extensions should be contacted in which order. In this case two extensions are returned as being interested in the information, along with the order in which they should be approached.
# The first relevant extension is contacted and carries out its work
# The first relevant extension returns the following values:
#* number: a string that contains the new number to dial (which may be the same as the input number to dial)
#* sendid: whether or not to send caller ID
#* authorized: if the action of making the call is authorized
#* authreason: if the action of making the call is not authorized then a reason why not
# The second relevant extension is contacted and carries out its work. Note that the parameters sent to this module include the updated number and sendid from the first relevant extension
# The second relevant extension returns the values as per the first extension
# The extension handler returns the final results in the reply to the calling method. At this stage gsmd should use the parameters returned rather than those it had prior to the call for the purposes of dialing a number and sending/not sending caller ID. It should also confirm that it is authorized to continue with the operation, and if not abort appropriately

=== Example of an Extension Registration ===

Extensions must be registered with the extension manager so that the extension handler is aware of them and can incorporate them in to extension requests. A pictorial representation of the registration process is shown below.

[[Image:Extensionframework_registration.png]]

# An extension sends a registration method to the extension manager. The method contains the following information:
#* extension. This is the full name of the method we wish to extend, for example org.openmoko.ExtensionHandler.Gsmd.OutgoingCall
#* name. This is the name of the object that is carrying out the extension, for example net.devzero.SampleExtension
#* path. This is the path to the object that is carrying out the extension, for example /net/devzero/SampleExtension
#* interface. This is the interface for the object that is carrying out the extension, for example net.devzero.SampleExtension
#* method. This is the method on the object that is carrying out the extension, for example GsmdOutgoingCall
# The extension manager logs the information in a central configuration store where it can be accesed by the extension handler
# The extension manager returns the call

Once an extension has registered a method then it will be called by the extension handler whenever required.

Unregistering an extension uses exactly the same methodology except that the method is Unregister rather than Register, all parameters stay the same.

=== Use Cases ===

There are a number of [[Wish List]] entries for which the extension framework could be used, these are as follows:
#[[Wish List#Mask ID based on dialed numbers|Mask outgoing caller ID based in dialed number]]
#[[Wish List#Use calling cards and similar routing techniques for lower-cost calling|Use calling cards and similar routing techniques for lower-cost calling]]
#[[Wish List#Outgoing black/white lists|Outgoing black/white lists]]
#[[Wish List#Time-based blocking/unblocking of calls|Time-based blocking/unblocking of calls]]

File:Extensionframework registration.png

2007-07-27T00:00:05Z

Jgm:

Wishlist/Extension Framework

2007-07-25T11:04:49Z

Jgm:

{{Wishlist}}

The extension framework is an application for handling extensions to the core OpenMoko functionality. It is designed to allow developers to build extensions that can affect the core functionality of the device without requiring extensive knowledge of, or even access to, the code that exists to carry out core functionality. It also allows for multiple extensions to affect the same core functionality, handling ordering and chaining of the extensions to ensure consistent results.

The rationale behind such a framework is to allow developers to create piecemeal functionality rather than having to alter or extend a large existing piece of code. Taking an outgoing call as an example there are a number of things that may be required around it, such as:

* only allow certain numbers to be dialed at certain times of the day
* only allow numbers in the addressbook to be dialed at certain times of the day, or a maximum number of times per day
* reroute calls using calling cards, low-cost numbers or similar methods
* reroute calls through a VOIP gateway
* mask caller ID depending on if the number called is in the addressbook
* update twitter with the fact that you are attempting to call someone, perhaps with details of the number (or name if they are in the addressbook)

Some of the above features are generally useful and would be expected to be made available in any complete 'phone implementation. Others are very unlikely to make it in to a core codebase. But all of them may be useful in a given situation, so for openmoko to be as flexible as possible these all need to be possible. As such, an extension framework that puts each user in control of what the 'phone will do in any given situation is the only way of providing both the required functionality as well as the core stability and speed that is required.

The extension framework consists of a number of entities, namely the extension manager, the extension configuration GUI and the extension handler. Each of these are discussed in more detail below.

=== Scope ===

The extension framework is initially aimed at providing a way of extending the core functionality of an OpenMoko device, and even more specifically of extending the abilities of the device in the area of making and receiving 'phone calls. However, there will be nothing in the design that limits it to handling just this area and indeed the design will allow for any type of extension given the correct method calls within the core code.

Note that the extension framework is not designed to manage GUI updating and interaction, although it is possible it could be used for this it is not designed to be a UI event bus and no consideration is given to this type of fucntionality.

=== Components ===

The extension framework will consist of three main components which will manage various aspects of managing and using the extensions. These components may or may not be separate processes, although there is a reliability advantage to having the handler separate from the other components. The names and functions of the three components are:

* The extension manager handles registration and activation of extensions as well as providing them a clean interface to store preference and configuration information.
* The extension handler carries out the work of receiving method calls to the extension manager, passing them to the relevant extensions and providing a final reply back to the calling method.
* The extension configuration GUI provides end users with the ability to configure each extension along with altering preferences and enabling/disabling specific features of each extension.

A final component of the extension framework will be a C library will provide extension developers with helper functions to achieve common tasks. This should allow extensions to be developed as quickly and efficiently as possible.

=== Example of a Method Call with the Framework Handler ===

For the following advantage we assume that gsmd is enabled for the extension framework. A pictorial representation of the framework is shown below.

[[Image:Extensionframework_method.png]]

#As gsmd gets ready to make a 'phone call it reaches the stage where it has set up all of its parameters and is about to start the process of making a call. It is at this point that the method call to the extension framework is made, by calling outgoingcall() with the following parameters:
#* number: a string that contains the number that gsmd was planning to dial (populated with the number passed in to the function)
#* sendid: whether or not to send caller ID (as per system or user default)
# When the extension handler receives this method it carries out a lookup of the extensions that are currently registered and active and puts together a list of which extensions should be contacted in which order. In this case two extensions are returned as being interested in the information, along with the order in which they should be approached.
# The first relevant extension is contacted and carries out its work
# The first relevant extension returns the following values:
#* number: a string that contains the new number to dial (which may be the same as the input number to dial)
#* sendid: whether or not to send caller ID
#* authorized: if the action of making the call is authorized
#* authreason: if the action of making the call is not authorized then a reason why not
# The second relevant extension is contacted and carries out its work. Note that the parameters sent to this module include the updated number and sendid from the first relevant extension
# The second relevant extension returns the values as per the first extension
# The extension handler returns the final results in the reply to the calling method. At this stage gsmd should use the parameters returned rather than those it had prior to the call for the purposes of dialing a number and sending/not sending caller ID. It should also confirm that it is authorized to continue with the operation, and if not abort appropriately

=== Use Cases ===

There are a number of [[Wish List]] entries for which the extension framework could be used, these are as follows:
#[[Wish List#Mask ID based on dialed numbers|Mask outgoing caller ID based in dialed number]]
#[[Wish List#Use calling cards and similar routing techniques for lower-cost calling|Use calling cards and similar routing techniques for lower-cost calling]]
#[[Wish List#Outgoing black/white lists|Outgoing black/white lists]]
#[[Wish List#Time-based blocking/unblocking of calls|Time-based blocking/unblocking of calls]]

Wish List

2007-07-25T11:02:32Z

Jgm:

This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [http://wiki.openmoko.org/wiki/Category:Ideas that have a category of 'Ideas'].

== Development ==
=== 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.

==== IDE Plugins ====
People like to see plugins for
* [http://anjuta.sourceforge.net Anjuta]
* [http://www.eclipse.org Eclipse]
* Game engine - Game Creation plugins
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]
* [http://www.kdevelop.org KDevelop]
* [http://developer.apple.com/tools/xcode/ XCode]
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]

==== UI Designer ====
Glade code generation is deprecated, 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 [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

==== Built-in Scripting Language ====

There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware. [[Wishlist:BuiltInScriptingLanguage]]
===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 [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html 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.

=== Software: Language bindings ===
==== Python bindings ====
Python bindings seem to be a commonly requested feature.

[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org 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 [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.

==== Other bindings ====
* Perl
* Ruby
* C#
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings

== Community Support ==

=== [http://projects.openmoko.org projects.openmoko.org] ===
Infrastructure for developers with
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)
* One mailing list for project

== Platform ==
=== 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.

=== Wishlist voting ===
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.

== Software: Additional features ==
===Calling===

==== Mask ID based on dialed numbers ====
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.

==== Use calling cards and similar routing techniques for lower-cost calling ====
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.

==== Outgoing black/white lists ====
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.

==== Time-based blocking/unblocking of calls ====
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.

====Speaker-phone====
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written.
====Advanced Airtime Tracking====
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.

==== Anti-stutter software ====
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.

====Minimize In-Call mode (check address book while in call)====
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.

Similar request when using the browser (lookup passwords, todo list, etc).

====Hold Music (Ringback Tone)====
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.
This can partially be implemented on the phone.
Issues are:
*In countries where callers pay, this will make you unpopular.
*In countries where the called party pays, it will use your minutes, or cost you money.
**A list of people to activate this function for would alleviate this.
*[[GPRS]] internet connection will stall while the hold music is being played.
*Extra battery used when playing music.

Also see [[Answering Machine]].

====Play sound clips over the air====
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104
The buttons can have default sounds, but also have the ability to be customized.

==== Conversation Recorder ====

An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.

====Unlicensed Mobile Access (UMA)====
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.

==== Ignore-Call Button ====

[[Wishlist:Ignore Call Button|Shut up a ringing phone]], without accepting or rejecting the call.

Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises.

==== [[Voice Mailbox]] ====

On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.
Can act profile-dependent.

==== Hold Button ====

Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.

==== Unanswered Call, Fast Call ====

In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.
Then the user of the mobile phone calls the other user(using the CallerID recognition).

===Audio===

==== Ambient Noise Detection ====

Using the microphone to [[Wishlist:Ambient Noise Detection|detect ambient noise]] the ringtone volume could be adjusted automatically.

Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.

==== Active noise control ====

Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.

==== Hear Impaired Mode ====

Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.

Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.

==== Mute Button ====

Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.

===Media===
====Music/Video Software====
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular.

Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.

==== Reading Support ====
It would be really great to be able to read :

*PDF
*Open Document files
*Text / RTF files
*MS Office files
*Aportis Doc (pdb)
*...

In both landscape and portrait

==== Wikipedia Mirror ====

See [[Wishlist:Wikipedia_Mirror|Wikipedia Mirror]].

==== Blog ScribblePad ====

Draw an image (and maybe add some text), then post to your blog.

==== E-Book Reader ====
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling. FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.

==== Personal Wiki ====

Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki]. [[Wishlist:PersonalWiki]]

[http://www.didiwiki.org/ Didiwiki]

==== Dictionary, thesaurus, translator and flashcards ====
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.

Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)

===PIM (Personal Information Managment)===
====Context Sensitivity====
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?

==== Address Book ====

* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP
servers or whatever.
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done
by integrating with whatever on-phone GPS mapping software the Neo ends up using.
* Random text input 'notes' about a contact
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.
* Support for:
**[http://en.wikipedia.org/wiki/SyncML SyncML]
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book.

==== Database/List Display/Edit ====

One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd. [[Wishlist:PilotDB]]

==== Joe's Goals ====

It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.

==== Workout ====

Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.

==== Shopping List ====
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.
==== Fuel Log ====
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).
Advanced features could include:
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)
* Sending the data to a central server which collects the information
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.

==== Keep in touch reminder ====
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.

==== Menstruation period timer ====
Fill in statistics and compute probabilities for menstruation, fertility, mood.
See http://www.getjar.com/products/48/MyGirls

==== [[Wishlist:Tagging|Tagging]] ====
Tags can be used by various applications. Requirement is interoperability for further enhancement.
Tags should be applied to calendar events, mail/sms, calls, places(GPS) and files.

==== Context based TO-DO list ====

If I arrive home and there are "@home" things in the to-do list, the [[Wishlist:context based to-do list|Context based to-do list]] reminds me of that.

==== Exchange Integration ====

Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.

* Is the time right to name names ? Add as your liking...
** Plugin/integration to & from Kontact
** Same with Evolution - Thunderbird - Seamonkey
** ?? Google Calendars ?? (this one is tough)

==== An electronic wallet ====

A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).

Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html]

===Profiles===

The [[Wishlist:Profiles]] page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.
And how to automatically switch between them.

===Text Messaging===
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included
For current development status of the messaging-app see: [[Messages]]

There are many useful options that now can be used to full capacity:
* '''Acknowledge/status SMS'''
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (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 receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.
** '''Special handling of status-SMS'''
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See:
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/
* '''Profile-override-SMS''' 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.
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "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: [http://en.wikipedia.org/wiki/SMS_language])
** Implement a script that abbreviates :-)
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel
* '''Searching''' allow full-text search or string search.
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.
* '''SMS-EMail-Gateway'''
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS

=== [[Wishlist:Text Input| Text input]] ===
There are many good suggestions for text input on the specific [[Wishlist:Text Input| text input ideas]] page.

=== More/Custom Input Method Widgets ===
Additional and customizable Input Method Widgets (similar to virtual keyboard).
This could add soft-key functionality to games or other applications such as:
*D-Pads
*buttons
*virtual trackballs
*...
Personalized layouts could be associated with each application.
See [http://wiki.openmoko.org/wiki/Wishlist:More/Custom_Input_Method_Widgets Input Method Wishlist] for more.

=== Games ===

Please see [[Wishlist:Games|the games page]].

=== Mesh Networking ===

Please see [[Wishlist:Mesh Networking|Mesh Networking]].

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

# GTK+'s printing support
# 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:
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]
* [http://www.j5live.com/?p=204 j5live.com]

===Misc Software===
====Clocks/timers/Activity meters====
===== Sport tracker =====
[[Wishlist:Sport_tracker|Sport tracker]] can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.

===== Standby clock =====
A quick way to see what [[Wishlist:Standby_clock|time]] it is.

===== Egg Timer =====

Very simple (one click) count up / count down timers are very useful. [[Wishlist:EggTimer]]

===== Cycle Computer =====
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)

====Calculators====
===== A Universal Unit Converter Tool =====

One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers.

Ideas what kind of conversions a converter tool could do:

Lenght
- Acceleration
- Angle
- Angular Velocity
- Area
- Capacitance
- Radioactivity
- Currency
- Charge
- Computer Memory
- Conductance
- Density
- Energy
- Illumination
- Power
- Force
- Flow
- Pressure
- Speed
- Temperature
- Time
- Torque
- Viscosity
- Volume
- Weight

Roman Numerals
- ASCII, Hex
- Cooking
- BMI
- Clothing Sizes

Physical and Mathematical Constants
GPS conversions

- link to or integration of a scientific calculator
- link to or integration of a simple calculator

A good basis for such a converter tool could be the Palm program "units" from
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.

For GPS conversions see gpsbabel [http://www.gpsbabel.org]

===== An Postfix Notation (RPN) calculator =====

Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.

==== Web-browser Plugins ====

* While an extensive browser plugin system would be costly to the efficacy of the platform three particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.

==== 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 thousands of PalmOS apps.

Win CE emulator
I'd like to see a Windows CE Emulator with active sync support.

==== TV Guide/Remote Control ====

Use your Phone to easily program your VCR using EPGs.

==== Alcohol meter ====
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.
See, for example (German text) http://www.misterio-online.de/promille.htm

==== Interaction with LEGO Mindstorm ====
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.

==== Flashlight ====
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!

=== Accessibility ===
Accessibility features for the visually impaired.
* High Contrast Themes.
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving.

==== VOIP ====
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.
* A standard SIP client would probably fit better into the "free and open" philosophy.

==== Power Meter ====
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.

=== Accelerometer wishes ===
==== Flick interface ====
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.

==== Reading navigation of documents enhanced by accelerometers ====
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.

I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)

==== Wand UI ====
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.

==== Shake-to-Wake ====
Giving the phone a shake enables voice commands for a few seconds.
Usage Examples:

{Shake} "Call" ''ContactName'' ''PhoneType'' --- {Shake} "Call John Mobile" (Calls John's mobile)

{Shake} ''ApplicationName'' --- {Shake} "Reader" (Opens the e-book application)

Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)

I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.

==== Emergency call ====
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.

A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).

=== Connectivity ===

==== VNC client ====
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.

==== Networked X-Windows ====

Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.

==== NX client ====

A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]

=== Security ===

==== My Account ====
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.

[[My Account]]
==== [http://zfoneproject.com/ Zfone] or similar ====

Something that allows the user to speak with another person securely.

==== GSM Encryption ====

This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel.

[[OSvS]]

==== My Voice is my Passport ====
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."

==== Firewall ====
A network firewall

==== Anti Theft Application ====

This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.

==Bluetooth==

=== Voice Dialing ===

Dial by voice commands. 
Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.

=== Music through Bluetooth Headset ===

Music can be played through a Bluetooth headset, but would stop playing when a call comes in.

=== Walkie Talkie ===

Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.

Features for this applications can be:
* Push To Talk (PTT) button
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.
* Optionally a full duplex mode
* Different channels to choose from
* Monitor different (preselected or all) channels for traffic.
* Content encryption
* Active noise control

Local (non-GPRS) use cases include chatting while biking
or motorcycling in a group; perhaps also in a car caravan.
This application could also be used as a baby-phone to monitor your siblings.

This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.

=== Automatic Sync ===

Automatically synchronize with desktop computer when within range based on user profile. This may require the use of a secure data transfer.

=== 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:
# Last known location
# 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.

=== Bluetooth neighbor detection and multiuser apps ===

Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.

=== Remote control ===

==== Wireless presenter ====
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature).
* If you want to be super-cool, you give a preview of the notes of the next slide in the show.
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.

==== Initiated from another device ====
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
==== Directed at another device ====
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.

Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]

=== Bluetooth Car Connection ===

Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.

==== Dude, Where's My Car? ====

When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.

=== [[Bluetooth powered Multi-SIM support]] ===

As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.

Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset
* Same for Short Messages/MMS/Internet
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.
Advantage: No 'switching' between cards
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.

===Internet Gateway===

If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.

=== Social Networking ===

Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.

== Other ==

=== Vibrate Pattern Recorder ===

An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).

One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.

- or just use MIDI, using a separate channel for the vibrator.

An implementation of RTTL could also be used to define vibration patterns.

=== PC Input Device ===

Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.

=== Advanced Notification And Ringtone Manager ===

[[Wishlist-ANARM|ANARM]] would be an application for handling all event-based audible notifications from an OpenMoko device.

=== Location based reminders ===
[[Wishlist:Location_based_reminders|Location based reminders]] can be used to notify users of various events or reminders that are location based.

=== Synergy Client ===
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]

== GPS Software ==
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features
** Overlay of satellite images with existing streetmaps
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seams like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.
[[Community Based Traffic Information]]

== Hardware ==
See [[Wish List - Hardware]]

[[Category:Ideas]]
It could be use for beepway Online service too
[http://www.beepway.com]

=== Tactile feedback via buzzer ===
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.

[[Category:User]]
[[Category:Ideas]]

Wishlist/Extension Framework

2007-07-25T10:51:07Z

Jgm:

{{Wishlist}}

The extension framework is an application for handling extensions to the core OpenMoko functionality. It is designed to allow developers to build extensions that can affect the core functionality of the device without requiring extensive knowledge of, or even access to, the code that exists to carry out core functionality. It also allows for multiple extensions to affect the same core functionality, handling ordering and chaining of the extensions to ensure consistent results.

The rationale behind such a framework is to allow developers to create piecemeal functionality rather than having to alter or extend a large existing piece of code. Taking an outgoing call as an example there are a number of things that may be required around it, such as:

* only allow certain numbers to be dialed at certain times of the day
* only allow numbers in the addressbook to be dialed at certain times of the day, or a maximum number of times per day
* reroute calls using calling cards, low-cost numbers or similar methods
* reroute calls through a VOIP gateway
* mask caller ID depending on if the number called is in the addressbook
* update twitter with the fact that you are attempting to call someone, perhaps with details of the number (or name if they are in the addressbook)

Some of the above features are generally useful and would be expected to be made available in any complete 'phone implementation. Others are very unlikely to make it in to a core codebase. But all of them may be useful in a given situation, so for openmoko to be as flexible as possible these all need to be possible. As such, an extension framework that puts each user in control of what the 'phone will do in any given situation is the only way of providing both the required functionality as well as the core stability and speed that is required.

The extension framework consists of a number of entities, namely the extension manager, the extension configuration GUI and the extension handler. Each of these are discussed in more detail below.

=== Scope ===

The extension framework is initially aimed at providing a way of extending the core functionality of an OpenMoko device, and even more specifically of extending the abilities of the device in the area of making and receiving 'phone calls. However, there will be nothing in the design that limits it to handling just this area and indeed the design will allow for any type of extension given the correct method calls within the core code.

Note that the extension framework is not designed to manage GUI updating and interaction, although it is possible it could be used for this it is not designed to be a UI event bus and no consideration is given to this type of fucntionality.

=== Components ===

The extension framework will consist of three main components which will manage various aspects of managing and using the extensions. These components may or may not be separate processes, although there is a reliability advantage to having the handler separate from the other components. The names and functions of the three components are:

* The extension manager handles registration and activation of extensions as well as providing them a clean interface to store preference and configuration information.
* The extension handler carries out the work of receiving method calls to the extension manager, passing them to the relevant extensions and providing a final reply back to the calling method.
* The extension configuration GUI provides end users with the ability to configure each extension along with altering preferences and enabling/disabling specific features of each extension.

A final component of the extension framework will be a C library will provide extension developers with helper functions to achieve common tasks. This should allow extensions to be developed as quickly and efficiently as possible.

=== Example of a Method Call with the Framework Handler ===

For the following advantage we assume that gsmd is enabled for the extension framework. A pictorial representation of the framework is shown below.

[[Image:Extensionframework_method.png]]

#As gsmd gets ready to make a 'phone call it reaches the stage where it has set up all of its parameters and is about to start the process of making a call. It is at this point that the method call to the extension framework is made, by calling outgoingcall() with the following parameters:
#* number: a string that contains the number that gsmd was planning to dial (populated with the number passed in to the function)
#* sendid: whether or not to send caller ID (as per system or user default)
# When the extension handler receives this method it carries out a lookup of the extensions that are currently registered and active and puts together a list of which extensions should be contacted in which order. In this case two extensions are returned as being interested in the information, along with the order in which they should be approached.
# The first relevant extension is contacted and carries out its work
# The first relevant extension returns the following values:
#* number: a string that contains the new number to dial (which may be the same as the input number to dial)
#* sendid: whether or not to send caller ID
#* authorized: if the action of making the call is authorized
#* authreason: if the action of making the call is not authorized then a reason why not
# The second relevant extension is contacted and carries out its work. Note that the parameters sent to this module include the updated number and sendid from the first relevant extension
# The second relevant extension returns the values as per the first extension
# The extension handler returns the final results in the reply to the calling method. At this stage gsmd should use the parameters returned rather than those it had prior to the call for the purposes of dialing a number and sending/not sending caller ID. It should also confirm that it is authorized to continue with the operation, and if not abort appropriately

Wishlist/Extension Framework

2007-07-21T13:38:32Z

Jgm:

{{Wishlist}}

The extension framework is an application for handling extensions to the core OpenMoko functionality. It is designed to allow developers to build extensions that can affect the core functionality of the device without requiring extensive knowledge of, or even access to, the code that exists to carry out core functionality. It also allows for multiple extensions to affect the same core functionality, handling ordering and chaining of the extensions to ensure consistent results.

The rationale behind such a framework is to allow developers to create piecemeal functionality rather than having to alter or extend a large existing piece of code. Taking an outgoing call as an example there are a number of things that may be required around it, such as:

* only allow certain numbers to be dialed at certain times of the day
* only allow numbers in the addressbook to be dialed at certain times of the day, or a maximum number of times per day
* reroute calls using calling cards, low-cost numbers or similar methods
* reroute calls through a VOIP gateway
* mask caller ID depending on if the number called is in the addressbook
* update twitter with the fact that you are attempting to call someone, perhaps with details of the number (or name if they are in the addressbook)

Some of the above features are generally useful and would be expected to be made available in any complete 'phone implementation. Others are very unlikely to make it in to a core codebase. But all of them may be useful in a given situation, so for openmoko to be as flexible as possible these all need to be possible. As such, an extension framework that puts each user in control of what the 'phone will do in any given situation is the only way of providing both the required functionality as well as the core stability and speed that is required.

The extension framework consists of a number of entities, namely the extension manager, the extension configuration GUI and the extension handler. Each of these are discussed in more detail below.

=== Scope ===

The extension framework is initially aimed at providing a way of extending the core functionality of an OpenMoko device, and even more specifically of extending the abilities of the device in the area of making and receiving 'phone calls. However, there will be nothing in the design that limits it to handling just this area and indeed the design will allow for any type of extension given the correct method calls within the core code.

Note that the extension framework is not designed to manage GUI updating and interaction, although it is possible it could be used for this it is not designed to be a UI event bus and no consideration is given to this type of fucntionality.

=== Components ===

The extension framework will consist of three main components which will manage various aspects of managing and using the extensions. These components may or may not be separate processes, although there is a reliability advantage to having the handler separate from the other components. The names and functions of the three components are:

* The extension manager handles registration and activation of extensions as well as providing them a clean interface to store preference and configuration information.
* The extension handler carries out the work of receiving method calls to the extension manager, passing them to the relevant extensions and providing a final reply back to the calling method.
* The extension configuration GUI provides end users with the ability to configure each extension along with altering preferences and enabling/disabling specific features of each extension.

A final component of the extension framework will be a C library will provide extension developers with helper functions to achieve common tasks. This should allow extensions to be developed as quickly and efficiently as possible.

=== Example of a Method Call with the Framework Handler ===

For the following advantage we assume that gsmd is enabled for the extension framework. A pictorial representation of the framework is shown below.

[[Image:Extensionframework_method.png]]

#As gsmd gets ready to make a 'phone call it reaches the stage where it has set up all of its parameters and is about to start the process of making a call. It is at this point that the method call to the extension framework is made, by calling outgoingcall() with the following parameters:
#* originalnumber: a string that contains the number that gsmd was planning to dial (populated with the number passed in to the function)
#* dialnumber: a string that contains the number that gsmd will dial on return (populated with the number passed in to the function)
#* sendid: whether or not to send caller ID (as per system default)
# When the extension handler receives this method it carries out a lookup of the extensions that are currently registered and active and puts together a list of which extensions should be contacted in which order. In this case two extensions are returned as being interested in the information, along with the order in which they should be approached.
# The first relevant extension is contacted and carries out its work.
# The first relevant extension returns the parameters that it could change (dialnumber and sendid) and also two additional parameters: authorized and authreason. These two parameters allow for any operation to be blocked by a suitable extension if required. If the extension handler ever sees a return parameter stating that an operation is not authorized then it will immediately send a suitable reply to the calling method informing it of the lack of authorization along with a text string containing a message suitable to be displayed to an end user explaining why it was not authorized.
# The second relevant extension is contacted and carries out its work. Note that the parameters sent to this module include the updated dialnumber and sendid from the first relevant extension.
# The second relevant extension returns the parameters that it could change (dialnumber and sendid) and also the authorization parameters as above.
# The extension handler returns the final results in the reply to the calling method. At this stage gsmd should update its parameters and carry on with the process of making the call, possibly with different parameters than when it started. It should also confirm that it is authorized to continue with the operation, and if not abort appropriately.

File:Extensionframework method.png

2007-07-21T13:34:28Z

Jgm: Sample method call for extension framework

Sample method call for extension framework

Wishlist/Extension Framework

2007-07-21T13:33:21Z

Jgm:

{{Wishlist}}

The extension framework is an application for handling extensions to the core OpenMoko functionality. It is designed to allow developers to build extensions that can affect the core functionality of the device without requiring extensive knowledge of, or even access to, the code that exists to carry out core functionality. It also allows for multiple extensions to affect the same core functionality, handling ordering and chaining of the extensions to ensure consistent results.

The rationale behind such a framework is to allow developers to create piecemeal functionality rather than having to alter or extend a large existing piece of code. Taking an outgoing call as an example there are a number of things that may be required around it, such as:

* only allow certain numbers to be dialed at certain times of the day
* only allow numbers in the addressbook to be dialed at certain times of the day, or a maximum number of times per day
* reroute calls using calling cards, low-cost numbers or similar methods
* reroute calls through a VOIP gateway
* mask caller ID depending on if the number called is in the addressbook
* update twitter with the fact that you are attempting to call someone, perhaps with details of the number (or name if they are in the addressbook)

Some of the above features are generally useful and would be expected to be made available in any complete 'phone implementation. Others are very unlikely to make it in to a core codebase. But all of them may be useful in a given situation, so for openmoko to be as flexible as possible these all need to be possible. As such, an extension framework that puts each user in control of what the 'phone will do in any given situation is the only way of providing both the required functionality as well as the core stability and speed that is required.

The extension framework consists of a number of entities, namely the extension manager, the extension configuration GUI and the extension handler. Each of these are discussed in more detail below.

=== Scope ===

The extension framework is initially aimed at providing a way of extending the core functionality of an OpenMoko device, and even more specifically of extending the abilities of the device in the area of making and receiving 'phone calls. However, there will be nothing in the design that limits it to handling just this area and indeed the design will allow for any type of extension given the correct method calls within the core code.

Note that the extension framework is not designed to manage GUI updating and interaction, although it is possible it could be used for this it is not designed to be a UI event bus and no consideration is given to this type of fucntionality.

=== Components ===

The extension framework will consist of three main components which will manage various aspects of managing and using the extensions. These components may or may not be separate processes, although there is a reliability advantage to having the handler separate from the other components. The names and functions of the three components are:

* The extension manager handles registration and activation of extensions as well as providing them a clean interface to store preference and configuration information.
* The extension handler carries out the work of receiving method calls to the extension manager, passing them to the relevant extensions and providing a final reply back to the calling method.
* The extension configuration GUI provides end users with the ability to configure each extension along with altering preferences and enabling/disabling specific features of each extension.

A final component of the extension framework will be a C library will provide extension developers with helper functions to achieve common tasks. This should allow extensions to be developed as quickly and efficiently as possible.

=== Example of a Method Call with the Framework Handler ===

For the following advantage we assume that gsmd is enabled for the extension framework. A pictorial representation of the framework is shown in .

#As gsmd gets ready to make a 'phone call it reaches the stage where it has set up all of its parameters and is about to start the process of making a call. It is at this point that the method call to the extension framework is made, by calling outgoingcall() with the following parameters:
#* originalnumber: a string that contains the number that gsmd was planning to dial (populated with the number passed in to the function)
#* dialnumber: a string that contains the number that gsmd will dial on return (populated with the number passed in to the function)
#* sendid: whether or not to send caller ID (as per system default)
# When the extension handler receives this method it carries out a lookup of the extensions that are currently registered and active and puts together a list of which extensions should be contacted in which order. In this case two extensions are returned as being interested in the information, along with the order in which they should be approached.
# The first relevant extension is contacted and carries out its work.
# The first relevant extension returns the parameters that it could change (dialnumber and sendid) and also two additional parameters: authorized and authreason. These two parameters allow for any operation to be blocked by a suitable extension if required. If the extension handler ever sees a return parameter stating that an operation is not authorized then it will immediately send a suitable reply to the calling method informing it of the lack of authorization along with a text string containing a message suitable to be displayed to an end user explaining why it was not authorized.
# The second relevant extension is contacted and carries out its work. Note that the parameters sent to this module include the updated dialnumber and sendid from the first relevant extension.
# The second relevant extension returns the parameters that it could change (dialnumber and sendid) and also the authorization parameters as above.
# The extension handler returns the final results in the reply to the calling method. At this stage gsmd should update its parameters and carry on with the process of making the call, possibly with different parameters than when it started. It should also confirm that it is authorized to continue with the operation, and if not abort appropriately.

External Feeds

2007-07-21T13:04:14Z

Jgm:

There are a number of blogs written by people in the [[OpenMoko]] community that are not part of the official feed, however can be accessed individually with the URLs below:

{| border="1"
! Blog Name !! Author !! Description !! Feed
|-
|devzero.net || [[User:Jgm|Jim McDonald]] || Application development (focused on messaging) || http://beta.blogger.com/feeds/6353086131724697255/posts/summary/-/openmoko
|-
|unethicalblogger.com || R. Tyler Ballance || Porting Mono to OpenMoko || http://unethicalblogger.com/blog_categories/openmoko/feed
|-
|}

[[Category:Information]]

User:Jgm

2007-07-21T13:01:37Z

Jgm:

Jim McDonald

External Feeds

2007-07-21T13:01:02Z

Jgm:

There are a number of blogs written by people in the [[OpenMoko]] community that are not part of the official feed, however can be accessed individually with the URLs below:

{| border="1"
! Blog Name !! Author !! Description !! Feed
|-
|devzero.net || [[:User:Jgm|Jim McDonald]] || Application development (focused on messaging) || http://beta.blogger.com/feeds/6353086131724697255/posts/summary/-/openmoko
|-
|unethicalblogger.com || || || http://unethicalblogger.com/blog_categories/openmoko/feed
|-
|}

[[Category:Information]]

External Feeds

2007-07-21T12:59:45Z

Jgm:

There are a number of blogs written by people in the [[OpenMoko]] community that are not part of the official feed, however can be accessed individually with the URLs below:

{| border="1"
! Blog Name !! Author !! Description !! Feed
|-
|devzero.net || [[User:jgm|Jim McDonald]] || Application development (focused on messaging) || http://beta.blogger.com/feeds/6353086131724697255/posts/summary/-/openmoko
|-
|unethicalblogger.com || || || http://unethicalblogger.com/blog_categories/openmoko/feed
|-
|}

[[Category:Information]]

Main Page

2007-07-16T12:46:08Z

Jgm: /* Misc. Development Related */

<big>'''Welcome to the [[OpenMoko]] public Wiki'''</big> 
For other languages see the [[#bottom|bottom]] of this page.

[[Image:FIC-neo1973_small.jpg|200px|right|frontside]]
[[OpenMoko]] is an [http://en.wikipedia.org/wiki/Open_source Open Source] project to create the world's first free mobile phone operating system.

The [[OpenMoko]] project is a community that anyone can join, to help design their ideal phone.

The long term goal is that phone software won't be tied to any particular phone. You can install any OpenMoko software over the whole range of phones, and if you upgrade your phone, you don't lose the software. Bugs fixed on one phone are fixed on all. To show that OpenMoko the phone stack is not tied to the Neo1973 phone hardware, here is a report from somebody who seems to have OpenMoko [http://blog.mikeasoft.com/2007/07/01/openmoko-on-a-treo-650/ up and limping on the Palm Treo650]!

'''Currently it is not suitable for users.''' The state of the software at the moment is pre-alpha. If you order a Neo1973, DO NOT expect to be able to use it as an everyday phone for several months.

The [[Neo1973]] from [[FIC]] is the first of many phones that [[OpenMoko]] will run on; indeed, some people erroneously use the terms Neo1973 and OpenMoko as interchangeable. If you are willing to have the alpha test experience, you can order Neo1973 hardware now from the [https://direct.openmoko.com/ Openmoko Online Shop]. You may wish to see the [[SH1 FAQ|Shipment 1 FAQ]].

Please join us in collaborating on the [[OpenMoko]] project through any of the [[Development resources | project resources]] including this OpenMoko wiki. Please see the [[Help:Contents | wiki editing help page]] for information on making contributions to this wiki. A [[Meet the Core Team | core team of developers funded by FIC, Inc.]] leads the project.

An [[introduction]] page is available, with [[Introduction#Photos|photos]] and [[Introduction#Videos|videos]]. Moreover, the usual [[FAQ | Frequently Asked Questions, FAQ, page]] might be helpful. Developers may find the [[ChangeLog | daily software change log]] an important resource.

The members of the [[OpenMoko]] community would like to thank [[FIC|FIC Inc.]] for showing leadership and initiating the [[OpenMoko]] project.

== [[OpenMoko]] Areas of Interest ==
* [[Basic End-user]] - Information for end users that want basic functionality and no surprises
* [[Advanced End-user]] - Information for advanced end-users that want advanced and experimental functionality but who are not programmers
* [[Development resources | Project Resources]] page provides a centralized location of all resources such as [[Development resources#Mailing_Lists|mailing lists]], [[Development resources#IRC | communication tools]], and other software development oriented resources.
* [[Application Developer]] - Information for application developers, including ideas and specifications for applications, and tools to build them
* [[System Developer]] - Information for system developers, including bootloader, kernel, and libraries
* [[Hardware Developer]] - Information for hardware developers, including hardware specs and debug board
* [[Community Events]] - Information on both [[Community Events#Past Events | past ]] and [[Community Events#Past Events#FIC / OpenMoko at Events | future]] events where FIC or [[OpenMoko]] had or will have a presence.

== Developer's Documentation ==

=== Hands-on Guides ===
* [[Getting Started with your Neo1973]]
* [[MokoMakefile|Building OpenMoko using the MokoMakefile]]
* [[Building OpenMoko from scratch]]
** Old [[Building OpenMoko from scratch (pre-BBT)]]
* [[Migration to bad block tolerant builds]]
* [[Running OpenMoko on PC]]
** [[Getting OpenMoko working on host with Xoo]]
** [[Getting OpenMoko working on host with Xephyr]]
** [[How to run OpenMoko Apps on PC]]
** [[OpenMoko under QEMU]]
* [[Booting from SD]]

=== Hardware Reference Documentation ===
* All [[:Category:Hardware|Hardware]] related documentation and specifications are found on the [[:Category:Hardware|Hardware page]].
* The [[:Category:Neo1973 Hardware|Neo1973 Hardware page]] provides an overview of the hardware components used by the [[:Category:Neo1973 Hardware|Neo1973 hardware platform]]. PCB Photographs are also included. A [[Disassembling Neo1973 | photo disassemble story]] may be an interesting starting place.
* [[:Category:Neo1973 Hardware Debugging | Neo1973 Hardware Debugging]] is assisted with the [[Debug Board | Neo1973 debug board]]. A page discussing [[Connecting Neo1973 with Debug Board v2 | debug board and Neo1973 configurations]] are also provided.

=== Software Reference Documentation ===
* Architectural
** [[OpenMokoFramework]] - The OpenMoko Application Framework
* [[neo1973 host software]]
* Device Software
** Low-Level
*** [[u-boot]] - The bootloader we use, including documentation for our modifications
*** [[kernel]] - The Linux kernel we use, including documentation for our modifications
** Userspace
*** [[binary compatibility]]
*** [[gsmd]] - the GSM daemon managing the GSM Modem
*** [[gpsd]] - the AGPS (Assisted GPS) daemon

=== OpenMoko===
* [[OpenEmbedded]] - The distribution-building framework
* [[Toolchain]] - The toolchain we use for compilation
* [[OpenMoko]] - The OpenMoko distribution
** [[OpenMoko2007]] - The first intended release of it
** [[Userspace root image]]

==== User Interface Related ====
* [[Look & Feel]]
* [[Applications]]
* [[Widgets]]
** [[Widget Inheritance Graph]]
* [[Application UI Design Recommendations]]

=== Misc. Development Related ===
* [[Freshman todo]]
* [[Templates]]
* [[PIM Storage]]
* [[Coding Guidelines]]
* [[OpenMoko#Setting_up_an_OpenMoko_SDK|How to setup the OpenMoko SDK]]
* [[License]] - How we license our code
* [[Development resources]] - Describes resources for developers (lists, svn, ...)
* [[Neo1973 Phase 0]] -- Information for Phase 0 device owners
* [[Wishlist:Neo1973 P0 Review]] -- Impressions of the Phase 0 hardware device, also the Phase 0 FAQ
* [[Neo1973 Phase 1]] -- Information for Phase 1 device owners
* [[Wishlist:Neo1973 P1 Review]] -- Impressions of the Phase 1 hardware device
* [[External Feeds]] -- List of feeds from people blogging about OpenMoko

== Administrative / Organizational ==

* [[Shipping Notes]] - Information to help FIC figure out how to ship products to you, and how much it might cost.
* [[My Account]] - Ideas for what sort of account-based services FIC should provide with the phone.

== Miscellaneous ==
* [[WiFi support in OpenMoko]]
* [[Neo1973 and Windows]] - If you want to commit that offence ;) (does not work, help!)
* [[Press Coverage]] - What the press says about the OpenMoko project
* [[mFAQ]] - The OpenMoko Misinformation FAQ ('''mFAQ''') - What the press '''''incorrectly''''' says about the OpenMoko project
* [[Wish List]] - A collection of ideas and ideals we'd like to see implemented some day
* [[Wish List - Hardware]] - A collection of ideas we'd like to see in the next Neo release
* [[Wishlist:BuiltInScriptingLanguage|Wish List - Built-in Scripting Language]] - Discussion on a suitable scripting language to be included
* [[Media Content]] - What types of media on the device can we use (that is non-software)?
* [[Testimonials]] - How did you get to OpenMoko?
* [[Buying Interest List]] - (Not official and not a pre-order page) Have you have put money aside for Neo1973? Put your nick here.
* [[iPhone]] - Comparison between Apple iPhone and FIC Neo1973
* [[Translation]] - Translation of OpenMoko
* [[Summer of code]] - Our page with project applications for Googles Summer of Code
* [[SWAG]] - Where to purchase openmoko swag (T-Shirts!)


{{Languages|Main_Page}}

[[Category:Information| ]]
[[Category:Categories| ]]

External Feeds

2007-07-16T12:37:29Z

Jgm: External blog feeds