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 that have a category of 'Ideas'.
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.
People like to see plugins for
evaluate eclipse project Device Software Development Platform Project from eclipse and subproject Tool for Mobile Linux
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
- Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?
Built-in Scripting Language
There was a 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
Infrastructure for developers with
- One bugzilla for all projects (makes moving bugs forth and backwards between projects very easy)
- One mailing list for project
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
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.
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.
There are many useful options that now can be used to full capacity:
- A feature to make it so even if you don't get service the OpenMoko will push text/chat messages to another persons phone's inbox if they are near you
- Not possible with current GSM networks, and if there was a central mail system by FIC, that implies tracking by FIC of every phone in real-time. Note also that GSM range is typically up to 15Km, whereas bluetooth is 15m or so.
- 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'.
- 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.
- You could be able to set up messages that are sent at a certain time/date
- Send binary SMS. Could be used to feign WAP pushes.  See:
- SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
- 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.
- 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: )
- Implement a script that abbreviates :-)
- Remind: T9 cannot be included in the phone. http://www.tegic.com/about/patent-list.asp it may be legally addable by users in some countries.
- a simple Finger-Based Applications to read and write sms in a fast way
- Dutton Speedwords. Maybe helpful?
- GPS fun. http://en.wikipedia.org/wiki/Gps2sms
- 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).
- 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
- Allow SMS-search in-text.
- Allow Massive Delete based on Conversation, author, before-date-xx.xx.xxxx, caller group...
- 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.
- Full finger-handling, next/previous/top-of-folder/reply (and my favorite: call Back)
- Leverage every email app in the universe by having an SM-email gateway on the phone:
- SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email.
- 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
- 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.
- 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
- 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: noscript, adblock plus, and greasemonkey.
- 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.
- 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.
There are many good suggestions for text input on the specific 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:
- virtual trackballs
Personalized layouts could be associated with each application. See Input Method Wishlist for more.
Please see the games page.
Please see Mesh Networking.
It would be really great to be able to read :
- Open Document files
- Text / RTF files
- MS Office files
- Aportis Doc (pdb)
In both landscape and portrait
See Wikipedia Mirror.
It would be really neat to be able to print over either bluetooth or USB. I can imagine wanting to print:
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.
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.
This is different from contextual profiles for mobile phones, that might for example turn off the ringer, and turn on 'vibrate', when you select 'quiet'.
They are profiles to let the owner of the phone set it up in a comfortable manner, without configuring every aspect.
- Beginner: Only basic functionality like, telephone and SMS
- Advanced: All in the "Beginner" profile, with e-mail, PIM functions
- Geek: every functionality you can get
- Granny: a minimum of functionality
- Child: Parents set limits for their child's phone.
- Employee: Employers set limits for their employees phones.
- Subscriber: Subsidised phone, with limits set for the user.
The first modes are easily switchable between by the user, as they are also the owner of the phone. In the Child, Employee, Subscriber cases, this is not be the case.
For example, for an employees phone, it may:
- Record GPS track log whenever it is in range of a certain bluetooth device (the employees company vehicle)
- Record all calls during working hours.
- Disallow installation of non-company-approved software.
For a child's phone, it may:
- Constantly record GPS once a minute.
- Mail GPS recordings to parents once an hour.
- Record all phone calls
- Disallow installation of software that is not 'child' rated.
For these modes to be tamper proof, it would require on-phone security. A version of u-boot that would only allow signed images and some application on owners PC to generate them, and set policy.
Very simple (one click) count up / count down timers are very useful. Wishlist:EggTimer
It'd be nice to have something like Joe's Goals always available, like my phone is, even when I'm disconnected from the net.
Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.
TV Guide/Remote Control
Use your Phone to easily program your VCR using EPGs.
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.
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
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.
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.
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
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.
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 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.
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.
Ambient Noise Detection
Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.
Shut up a ringing phone, without 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.
Button to temporarily disable microphone while talking.
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.
Automated profile switching
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/...
Profile zoning - define different zones for switching different profiles automatically either by GPS zoning, Wi-Fi proximity or GSM base station proximity.
Profile scheduling - more complex than timeout. Ability to create a schedule for activating different profiles, or integrate profile switching with the schedule.
Context based TO-DO list
I arrives to home and there is some "@home" things in the to-do list, the Context based to-do list reminds me that.
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)
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.
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.
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.
Location based reminders
Location based reminders can be used to notify users of various events or reminders that are location based.
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.
A quick way to see what time it is.
As already mentioned by 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 :) --Minime 19:50, 12 April 2007 (CEST)
Internet Connection Management
An application that automatically chooses the best available connection method, between Bluetooth, USBnet, Wifi, GPRS, etc. For GPRS or other services where the user may be paying per kb, there should be options to limit data transfer. The user could be asked permission to transfer data: per connection, per process, per process for a specific time limit, per process for a specific data size limit, etc.
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. Synergy
Software: Language 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."
- I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings
Software: Foreign Widget Set Bindings
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.
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 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 is the game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.