< Maliit(Difference between revisions)
|
|
| (36 intermediate revisions not shown) |
| Line 1: |
Line 1: |
| - | [[Category:Maliit]][[Category:MeeGo Input Methods]]
| + | Moved (upstream) to http://wiki.maliit.org/Ideas |
| - | | + | |
| - | {{MaliitNavigationBar}}
| + | |
| - | | + | |
| - | 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.
| + | |
| - | | + | |
| - | === Template Idea ===
| + | |
| - | Short description of the idea.
| + | |
| - | | + | |
| - | '''Difficulty/effort:''' Easy, 5 hours of work | Hard, 2 weeks of work. <br>
| + | |
| - | '''Skills required:''' Qt | Packaging | Gtk+ | QML <br>
| + | |
| - | | + | |
| - | 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 Method (plugin) Ideas ==
| + | |
| - | | + | |
| - | === Key gestures ===
| + | |
| - | 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.
| + | |
| - | | + | |
| - | === Predictive keyboard ===
| + | |
| - | 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 input method ===
| + | |
| - | [[:wikipedia:Dasher|Dasher]] is a simple but innovative way of doing text input, a for this plugin would be very useful.
| + | |
| - | | + | |
| - | === QML-based plugin ===
| + | |
| - | Show that input method plugins can be implemented using Qt Quick and QML. In the simplest case, this could be done using <code>QDeclarativeView</code>, and some QML wrappers for <code>MInputMethodConnection</code>.
| + | |
| - | | + | |
| - | === Clutter-based plugin ===
| + | |
| - | Show that input method plugins can be implemented using Clutter. This should be easy to do using [http://git.clutter-project.org/cgit.cgi?url=clutter-qt/tree/README clutter-qt].
| + | |
| - | | + | |
| - | === Gtk+ based plugin ===
| + | |
| - | 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 <code>QWidget</code> and a <code>GtkWidget</code> and syncronize the relevant state between them. Let the GtkWidget render offscreen and paint the GtkWidget content to the <code>QWidget</code> in <code>::paintEvent()</code>.
| + | |
| - | | + | |
| - | === Bluetooth keyboard ===
| + | |
| - | This would allow you to use your Meego device as a keyboard for other Bluetooth enabled devices.
| + | |
| - | | + | |
| - | == Different run-time environments ==
| + | |
| - | | + | |
| - | === Meego Input Methods in GNOME Shell ===
| + | |
| - | 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.
| + | |
| - | | + | |
| - | * [https://live.gnome.org/ThreePointOne/Features/OnScreenKeyboard Gnome 3.2 Feature page]
| + | |
| - | * [https://bugzilla.gnome.org/show_bug.cgi?id=612662 Issue in bugtracker]
| + | |
| - | | + | |
| - | === Meego Input Methods on Windows ===
| + | |
| - | 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.
| + | |
| - | | + | |
| - | === Meego Input Methods in KDE ===
| + | |
| - | KDE also seems to be growing an interest in on-screen keyboards, touchscreen centric UI and mobile device form factors.
| + | |
| - | | + | |
| - | * [http://btux1984.wordpress.com/2010/04/28/kdes-onscreen-keyboard Blogpost]
| + | |
| - | * [https://bugs.kde.org/show_bug.cgi?id=265452 Issue in bugtracker]
| + | |
| - | | + | |
| - | == Other ==
| + | |
| - | === Commandline option to switch between D-Bus session bus and direct socket ===
| + | |
| - | 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?).
| + | |
| - | | + | |
| - | === Free and open source correction/prediction plugin ===
| + | |
| - | 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.
| + | |
| - | | + | |
| - | === Window relocation ===
| + | |
| - | 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 <br>
| + | |
| - | '''Skills required:''' X11, ICCM, EWMH <br>
| + | |
| - | | + | |
| - | 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 [[http://tronche.com/gui/x/xlib/input/XGetInputFocus.html 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 [[http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2447157 _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.
| + | |
| - | | + | |
| - | == Completed ideas ==
| + | |
| - | Please move ideas here one they have been implemented/explored, and document the effort.
| + | |
| - | | + | |
| - | {{MaliitNavigationBar}}
| + | |