| Maliit - Input Methods for MeeGo |
|---|
| Overview · Development · Installing · Roadmap |
Here are some ideas for what you could do with Meego Input Method framework. Some are down-to-earth while others are perhaps a bit more in the experimental or show-that-it-can-be-done spirit. Feel free to add ideas here. Use the template idea if you want. For bugs or concrete features suggestions, please use the bugtracker.
Contents |
Short description of the idea.
Difficulty/effort: Easy, 5 hours of work | Hard, 2 weeks of work.
Skills required: Qt | Packaging | Gtk+ | QML
Longer description. Ideas, challenges, and considerations for the implementation. Neccesary tasks to complete. Links to other relevant projects or work. Mockups, video demos, et.c.
Input variations of a character using gestures on that key. For instance, to input a upper case A, tap 'a', move upward and release. Accented characters can be done by gesturing sideways.
Details of idea can be found under Predictive_virtual_keyboard. This should perhaps be done for the existing Meego Keyboard?
Experimental MRQ available: https://meego.gitorious.org/meegotouch/meegotouch-inputmethodkeyboard/merge_requests/269
Dasher is a simple but innovative way of doing text input, a for this plugin would be very useful.
Show that input method plugins can be implemented using Qt Quick and QML. In the simplest case, this could be done using QDeclarativeView, and some QML wrappers for MInputMethodConnection.
Show that input method plugins can be implemented using Clutter. This should be easy to do using clutter-qt.
Show that input method plugins can be implemented using Gtk+. A bit harder than the Clutter case, but should be possible. In the simple but hacky form have a QWidget and a GtkWidget and syncronize the relevant state between them. Let the GtkWidget render offscreen and paint the GtkWidget content to the QWidget in ::paintEvent().
This would allow you to use your Meego device as a keyboard for other Bluetooth enabled devices.
Gnome looks to be interested in expanding to touch-centric environments. Therefore showing that Meego Input Methods could work in the default GNOME3 experience, Gnome Shell would be cool.
The main goal here would be to allow plugin development to happen on Windows. Since Meego Input Methods is implemented using Qt, this should in theory not be too hard. However, the DBus transport used between framework and inputcontext might need to be replaced by another IPC, and some X specific code might need to be reimplemented or removed.
KDE also seems to be growing an interest in on-screen keyboards, touchscreen centric UI and mobile device form factors.
Basically, revert http://meego.gitorious.org/meegotouch/meegotouch-inputmethodframework/commit/1aa9a502005293bf4a808aaed87142f6dbcdffdb but add a commandline option to choose between the two methods. This allows one to make use of DBus features like on-demand service activation, or to easily introspect/debug the service. The standard input contexts should be updated to also support session bus service (and prefer that one over the socket?).
Currently there is no free error correction/prediction engine. We of course want this. This could be done pretty easily using one of the existing free spelling engines (Aspell, Ispell, Hunspell, Enchant). From a very brief look at things, Enchant seems to be the best option.
When the application/toolkit does not support widget relocation, fall back to relocating the window to try to keep the text input field visible on screen.
Difficulty/effort: Medium, 15 hours of work
Skills required: X11, ICCM, EWMH
Status: Prototype work in progress by Jon Nordby
There are two main ways of doing this:
1. Move/resize the focused window
Getting hold of the window can for instance be done using XGetInputFocus or the winId attribute of the widgetstate provided by the input context.
2. Move/resize all windows. Easiest way to do this is probably to create a proxy X window for the region covered by the input method, and setting the _NET_WM_STRUT_PARTIAL hint. This moves the responsibility of the actual relocation to the window manager.
Both approaches can be implemented solely in IM framework. For a good solution, each input context needs to be able to tell the framework if it can do widget relocation or not, and how much relocation it can to. Then, the framework and input context would have to cooperate on the actual relocation, effectively adding the window as another level to the relocation chain.
When the window is resized, the toolkit will hopefully maintain the focused input widget visible on screen. It is however not certain that this is the case with common toolkits. Patches might be needed.
Please move ideas here one they have been implemented/explored, and document the effort.
| Maliit - Input Methods for MeeGo |
|---|
| Overview · Development · Installing · Roadmap |