IDE Plugins

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 the relevant bug entry

Community Support

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.

Software: Additional features

Text Messaging

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

In GSM networks so-called acknowledge-sms are sent back to the sms's dispatcher in order to indicate that the primal sms was recieved (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.

You could be able to set up messages that are sent at a certain time/date

SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.

Implement a script that de-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: [6])

Why should we use SMS for that task? Jabber or something similar would be much better and cheaper

Input help (which as a matter of fact does not belong to text messaging but input in general): I guess there won't be any T9 as it's not open. Alternatives? (Let's make the worlds most convenient input method for mobiles :-) See: http://en.wikipedia.org/wiki/Predictive_text

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

Text input

Something like HexInput would be very interesting to try. Especially versions of the QUONG layout. Different variations for different languages will be needed.

Another possibility would be to use Dasher along with the touchpad interface.

Multiboot Support

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

PalmOS Emulator

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

Special Profiles

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

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.

Ambient Noise Detection

Ignore-Call Button

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.

Mute Button

Button to temporarily disable microphone while talking.

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.

Silent mode timeout

With a "silent mode" timeout, there is no need to turn the ringer back on if you previously know how long will be the film/meeting/...

Context based TO-DO list

Bluetooth neighbor detection and multiuser apps

Like the 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.

Exchange Integration

Once there is good TCP/IP connectivity on this phone, integration with corportate email/calendar/todo/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.

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.

Bluetooth Walkie Talkie

Let OpenMoko devices connect to one another via bluetooth and hold a conversation. Depending on the effective range between two devices, this might be a very silly thing to do, so maybe it's only purpose is as a fun toy application.

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

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

Bluetooth Car Connection

Have a deeper connection to the car than just handsfree speakerphone. For instance a transciever 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.

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 and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation.

Location based reminders

Software: Language bindings

Python bindings

Python bindings seem to be a commonly requested feature.

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

C++ bindings

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

Other bindings

Perl

Ruby

C#

Software: Foreign Widget Set Bindings

Qt Integration

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

Maemo Integration

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

wxWidgets Integration

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

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

SDL Integration

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

IDE Plugins

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 the relevant bug entry

Community Support

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.

Software: Additional features

Text Messaging

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

In GSM networks so-called acknowledge-sms are sent back to the sms's dispatcher in order to indicate that the primal sms was recieved (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.

You could be able to set up messages that are sent at a certain time/date

SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.

Implement a script that de-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: [6])

Why should we use SMS for that task? Jabber or something similar would be much better and cheaper

Input help (which as a matter of fact does not belong to text messaging but input in general): I guess there won't be any T9 as it's not open. Alternatives? (Let's make the worlds most convenient input method for mobiles :-) See: http://en.wikipedia.org/wiki/Predictive_text

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

Text input

Something like HexInput would be very interesting to try. Especially versions of the QUONG layout. Different variations for different languages will be needed.

Another possibility would be to use Dasher along with the touchpad interface.

Multiboot Support

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

PalmOS Emulator

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

Special Profiles

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

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.

Ambient Noise Detection

Ignore-Call Button

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.

Mute Button

Button to temporarily disable microphone while talking.

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.

Silent mode timeout

With a "silent mode" timeout, there is no need to turn the ringer back on if you previously know how long will be the film/meeting/...

Context based TO-DO list

Bluetooth neighbor detection and multiuser apps

Like the 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.

Exchange Integration

Once there is good TCP/IP connectivity on this phone, integration with corportate email/calendar/todo/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.

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.

Bluetooth Walkie Talkie

Let OpenMoko devices connect to one another via bluetooth and hold a conversation. Depending on the effective range between two devices, this might be a very silly thing to do, so maybe it's only purpose is as a fun toy application.

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

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

Bluetooth Car Connection

Have a deeper connection to the car than just handsfree speakerphone. For instance a transciever 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.

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 and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation.

Location based reminders

Software: Language bindings

Python bindings

Python bindings seem to be a commonly requested feature.

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

C++ bindings

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

Other bindings

Perl

Ruby

C#

Software: Foreign Widget Set Bindings

Qt Integration

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

Maemo Integration

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

wxWidgets Integration

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

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

SDL Integration

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