m (→Predictive keyboard) |
(→Free and open source correction/prediction plugin) |
||
| Line 93: | Line 93: | ||
This could be done using one of the existing free spelling engines. | This could be done using one of the existing free spelling engines. | ||
| - | An analysis of the different options should be done before starting on the implementation, looking at the advantages/disadvantages of each. | + | An analysis of the different options should be done before starting on the implementation, looking at the advantages/disadvantages of each. For instance, it might not be that all spelling engines can provide word-prediction. |
| - | * Aspell | + | * [http://aspell.net/ Aspell] |
| - | * Ispell | + | * [http://www.gnu.org/software/ispell/ispell.html Ispell] |
| - | * Hunspell | + | * [http://hunspell.sourceforge.net/ Hunspell] |
| - | * Enchant | + | * [http://www.abisource.com/projects/enchant/ Enchant] |
* ? | * ? | ||
| 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: How much work does it take to complete this (assuming a Maliit dev. environent is already set up) Example: Easy, 5 hours of work
Status: What is the status of implementing this idea? Example: "In progress, this and that has been done"
Skills required: What do people need to know in order to complete the implementation of this idea? Example: Qt | Packaging | Gtk+ | QML
Contact person: Who interested people should contact if they want to work on this. This can be a "mentor" that has insight into the relevant areas, or someone who has started working on it. Example: Real Name (ircnick)
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.
Difficulty/effort: Easy, 10 hours of work
Skills required: Meego keyboard, Qt, C++
Status: Experimental merge request available
Contact person: Michael Hasselmann (mikhas)
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 Maliit is the right solution to use for input methods in Gnome would be worth-while.
Difficulty/effort:
Skills required: Gnome technology, Maliit integration
Status: Prototype work has been demonstrated
Contact person: Jon Nordby (jonnor)
TODO: document all the things needed for really good integration
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.
Currently a peer-to-peer connection with a socket file is used for input context <-> framework communication. Having a option to use the session bus would be nice. This allows one to make use of DBus features like on-demand service activation, or to easily introspect/debug the service.
Difficulty/effort: Easy, 20 hours of work
Skills required: dbus, dbus-glib, C/C++
Status:
Currently there is no free error correction/prediction engine plugin. We of course want to provide this.
Difficulty/effort: Easy, 20 hours of work
Skills required: C/C++, usage of spelling engines
Status: Just talk. Help wanted!
This could be done using one of the existing free spelling engines. An analysis of the different options should be done before starting on the implementation, looking at the advantages/disadvantages of each. For instance, it might not be that all spelling engines can provide word-prediction.
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
Contact person: Jon Nordby (jonnor)
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. It might be necessary to use both, because applications frequently makes use of the "desktop area" when they decide how big they can make their visual elements.
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 |