View source for Wish List
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Templates used on this page:
Return to Wish List.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Templates used on this page:
Return to Wish List.
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'.
Our goal should be a completely painless setup for somebody wanting to develop using OpenMoko
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
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
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.
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.
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.
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.
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).
You know how on most cellphone networks you can pay so that people will hear music when they call you? I think we should do that. If this option is turned on (maybe it could be set for each person in your phone book) the Neo can automatically answer the call, mute the microphone, and play the selected sound file over the GSM connection to the caller. To you the Neo looks exactly as it does when anybody calls you, but behind the scenes it's playing music for the caller. When you answer the call, the music fades out and the microphone comes back on. Of course, callers could abuse this feature costing you minutes, which is why it should be individually set for each entry in the phonebook (defaulting to off) and you can only turn it on for people you trust.
Dialer could have a tab with big buttons which, when push, send sound bytes 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.
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.
Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.
Using the microphone to do 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.
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.
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.
Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.
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.
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.
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:
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.
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
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.
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 may not be the case.
For example, for an employees phone, it may:
For a child's phone, it may:
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.
Allow the use of Cell Id's rather than GPS coordinates to activate/deactivate/change profiles/things on the device. Cell Id changes could trigger scripts etc. (Store them in sqlite db?)
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.
servers or whatever.
by integrating with whatever on-phone GPS mapping software the Neo ends up using.
It would be really great to be able to read :
In both landscape and portrait
There are many good suggestions for text input on the specific text input ideas page.
Additional and customizable Input Method Widgets (similar to virtual keyboard). This could add soft-key functionality to games or other applications such as:
Personalized layouts could be associated with each application. See Input Method Wishlist for more.
Please see the games page.
Please see Mesh Networking.
See Wikipedia Mirror.
Draw an image (and maybe add some text), then post to your blog.
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
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:
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.
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.
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.
Very simple (one click) count up / count down timers are very useful. Wishlist:EggTimer
Display the notes database as a Wiki. Inspiration: AcroWiki. Wishlist:PersonalWiki
One of the most useful apps on my Palm Pilot for me is pilot-db. It's GPL'd. Wishlist:PilotDB
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.
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:
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!)
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.
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
Fill in statistics and compute probabilities for menstruation, fertility, mood. See http://www.getjar.com/products/48/MyGirls
With the accelerators, 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.
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 features for the visually impaired.
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.
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.
Something that allows the user to speak with another person securely.
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.
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 (accelerators)
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.
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.
User should be able to define multiple profiles based on their tariff plan. I guess this has to be slightly modified accordingly to the various country differences over the world; PC side apps for easily defining profiles is needed. PC side based apps should be able at least to output in standard database format, xml, html.
Ideally users would be able to monitor their use of their smartphone basing on various paramethers such kb exchanged on various acces (GPRS/EDGE/UMTS) and connection time, calls number, frequency, duration, contacts called, etc. User should be able to set alarms based on limits and even password protected blocks if configured. Alarms for cheaper time for using the smartphone payed services if time day based tariff plan occurs would be helpfull. This data sould be stored securely or encrypted if possible as privacy care.
The ability to place a unit's point in space in relation to other units. I have no idea which RF carrier would be best suited for the task, but I'm thinking Wifi for the range.
Unfortunately not possible with the hardware in the device. Commodity wi-fi devices don't time the RF to this accuracy. --Speedevil 16:55, 13 July 2007 (CEST)
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.
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 can be played through a Bluetooth headset, but would stop playing when a call comes in.
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:
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.
Automatically synchronize with desktop computer when within range based on user profile. This may require the use of a secure data transfer.
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:
Each target device is configured as follows:
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:
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.
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.
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.
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
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. www.z-wave.com
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.
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.
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:
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.
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.
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.
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.
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.
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.
Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.
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 can be used to notify users of various events or reminders that are location based.
Suppose you are in a busy environment and your device is lying around somewhere. You sometimes use it but cannot look after it all the time. A sort of high risk environment for phone theft where you could put it in anti theft mode which is enabled when someone moves it or touches the touch screen. This, of course will be set off after a predefined time out awaiting a password to unlock this mode (unprompted?). From the moment it has been moved or touched it will display a warning on a red background flashing in black: You are committing a crime. Put this phone back, now! or any other predefined text. If it is not unlocked it will set off a loud alarm and start sending messages to a predefined email address with pictures, GPS coordinates and network pings.
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.
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
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.
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."
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.
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.