Meego Wiki
Views
From MeeGo wiki
< Maliit
Revision as of 20:06, 9 June 2011 by Jonnor (Talk | contribs)
Jump to: navigation, search


Maliit - Input Methods for MeeGo
Overview · Development · Installing · Roadmap

Here are some ideas for what you could do with Maliit. Some are things we really want to get done (but have not committed to), some are down-to-earth nice-to-have, while others are perhaps a bit more in the crazy, 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

Template Idea

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.

Meego Keyboard 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.

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

Screenshot/demo video pleaz? -- Was demonstrated during the Meego Conference San Fransisco talk. Video will hopefully become available

Input Method (plugin) Ideas

Dasher input method

Allow input using a Dasher input method.

Difficulty/effort: Unknown, 25 hours of work?
Skills required: C/C++, Qt, input method API
Status: Just talk!
Contact person:

Dasher is a simple but innovative way of doing text input, a for this plugin would be very useful, especially for accessibility. Dasher already has a Qt based UI, so it might be possible to reuse large parts of the code.

Clutter-based plugin

Show that input method plugins can be implemented using Clutter.

Difficulty/effort: Easy, 15 hours of work
Skills required: Clutter, input method API
Status: Just talk!
Contact person:

This should be easy to do using clutter-qt. Ideally writing such would not require to compile using C++/Qt, but a C/GObject interface be provided.

Gtk+ based plugin

Show that input method plugins can be implemented using Gtk+.

Difficulty/effort: Medium, 15 hours of work
Skills required: Gtk+, Qt, input method API
Status: Just talk!
Contact person:

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().

Python input method plugin interface

Support writing input methods in Python.

Difficulty/effort: Medium, 15 hours of work
Skills required: Python, PySide, input method API
Status: Just talk!
Contact person:

Python is an officially supported language for Meego. It would be nice if we supported writing plugins using Python. Allowing this can be done in a similar way we currently support QML (see input-method-quick code) Python bindings would have to be generated for the input method API. This should probably be done using PySide.

Non-Meego run-time environments

Maliit in Gnome 3

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:

  • For prototype demo: Easy, 20 hours of work
  • For really good integration: Medium, xxx hours of work

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

Maliit 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.

See also Maliit/Ideas/Supporting_Non_X11_Platforms

Maliit in KDE

KDE also seems to be growing an interest in on-screen keyboards, touchscreen centric UI and mobile device form factors.

Difficulty/effort:

  • For prototype demo: Easy, 10 hours of work
  • For really good integration: Medium, xxx hours of work

Skills required: KDE technology, Maliit integration
Status: ?
Contact person:

Maliit in Ubuntu

Other

Commandline option to switch between D-Bus session bus and direct socket

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:

Direct C/C++ Input Context API

Direct API for input context (no DBus connection).

Difficulty/effort: Easy, 15 hours
Skills required: Qt, C++, input context api
Status:
Contact person:

A direct API means that the framework can be tested without having to start up DBus, and that it can run on platforms with DBus.

Free and open source correction/prediction plugin

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.

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
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.

Input Method Plugin SDK

Development kit to enable third-party developers to easily create new input methods.

Difficulty/effort: Easy, 20 hours of work
Skills required: Input Method plugin API
Status: Still room for improvement
Contact person: Jon Nordby (jonnor)

Current plugin SDK available from Maliit/Documentation

A good SDK would consist of:

  • (80%) Comprehensive documentation for plugin API
  • (60%) Task-oriented documentation for how to develop a plugin
  • (DONE) Skeleton/example code to make it easy to get started
  • (DONE) Above items easily available for the target platforms
  • (TODO) Tools/utilities to make development easier
    • Currently setting the correct plugin requires fiddling with gconf
    • Currently one has to run/restart the uiserver manually
    • Currently running the test application with the correct inputcontext has to be done manually

Bluetooth keyboard

This would allow you to use your Meego device as a keyboard for other Bluetooth enabled devices.

Completed ideas

Please move ideas here one they have been implemented/explored, and document the effort.

QML-based plugin

Show that input method plugins can be implemented using Qt Quick and QML.

Status: Done!
Contact person: Michael Hasselmann (mikhas)

A QML-based input method plugin (keyboard) can be found in the keyboard repositor under meego-keyboard-quick. See the blogpost announcement for more details.

Maliit on Freemantle+N900

Demonstrate that Maliit can run on Freemantle/N900.

Status: Done!
Contact person: Michael Hasselmann (mikhas)

Maliit framework and the Meego Quick keyboard is available in the extras-devel repository. See [Maliit/Installing] for how to install. The announcement blogpost also has some info.

Maliit - Input Methods for MeeGo
Overview · Development · Installing · Roadmap
Personal tools