Input Sources

Status: Implementation in progress

Description

We want to integrate input methods and keyboard layouts in a understandable, uniform way in GNOME 3. This integration will affect both the shell input menu and in the control-center region panel. The existing designs are here: GnomeShell/Design/Guidelines/SystemStatus/InputLanguage, Design/SystemSettings/RegionAndLanguage.

The desired experience is that the user selects an 'input language' or 'input source', which controls both keyboard layout and input method; in particular, the experience should be the same whether IBus is being used or just plain XKB.

The architecture of this code has changed a bit over time. The current approach uses a gnome-settings-daemon plugin as the central place to coordinate and update all relevant settings for input method modules, XKB keyboard layouts and IBus configuration. Both the gnome-shell menu and the gnome-control-center panel will simply talk to gnome-settings-daemon.

Owner

Rui Matos

Involved Parties

gnome-shell, control-center, libgnomekbd, ibus, Takao Fujiwara, Allan Day

Current Status

This feature is tracked in various bugs:

• bug 662489 (gnome-control-center) region: implement input sources

• bug 641531 (gnome-shell) Integration of keyboard indicator with input methods

• bug 676102 (gnome-settings-daemon) XKB keyboard layouts and IBus integration

• bug 676583 (gnome-desktop) Add a class to parse and make XKB xml descriptions available

• bug 676101 (gsettings-desktop-schemas) Input sources settings schema

• bug 679643 (jhbuild) Add ibus dependency for g-s-d and g-c-c

• bug 678172 (gnome-control-center) keyboard: allow compose key and 3rd level chooser customization

High Priority for 3.6:

• bug 680313 (gnome-settings-daemon) keyboard: deal with input methods for non-gtk apps

• bug 664041 (gnome-shell) Search field in the overview does not support preedit

• bug 658325 (gnome-shell) ViewSelector does not accept to commit the strings from input method

• bug 682313 (gnome-control-center) switch from a whitelist to a blacklist

• GnomeOS/Design/Whiteboards/KeyboardShortcuts find a good shortcut for switching input sources

• bug 681685 (gnome-control-center) Allow setting shortcut based only on a combination of two modifier keys, eg. Alt+Shift

• bug 678171 (gnome-tweak-tool) add keyboard layout options

• bug 682314 (gnome-shell) add hiragana/katakana items to keyboard status menu

• rh bug 8453017 (gtk2) Make gtk2 apps behave the same as gtk3

Nice to have for 3.6:

• bug 683015 (gnome-shell) st-im-text: Support surrounding-text

• bug 682315 (gnome-shell) add an OSD for cycling through engines

• bug 682240 (gnome-control-center) Option to enable extra keyboard layouts

• bug 679819 (gnome-settings-daemon) 3.6: fallback and keyboard configuration

• bug 682316 (gnome-control-center) support language-dependent defaults for shortcuts

Post 3.6 enhancements:

• bug 681735 (gnome-shell) on-screen keyboard layout does not update

• bug 682317 (gnome-control-center) Improve 'add' dialog

• bug 682318 (gnome-shell) add more engine options to keyboard status menu

• bug 682319 (gnome-settings-daemon) handle language-specific input keys

• bug 682324 (gnome-shell) Make 'Add to dictionary' available in context

Notes from the GUADEC Input Sources BoF

The basic functionality of this feature has been included in 3.5.4.

There has been a lot of discussion around this feature on desktop-devel-list in May 2012, with various people arguing for other input method frameworks, or against integrating any single framework. Halfway through the discussion, Owen wrote a nice summary of the position and motivation of the people working on this feature. It is long, but worth reading.

The main points are:

• It is essential that we choose a single input method framework. It is not possible to create the unified integrated user experience we want while supporting arbitrary, loosely coupled frameworks.
• Most frameworks use the same backend libraries and dictionaries for implementing their actual input methods anyway (anthy, m17n, ...)
• IBus may not be the only possible choice for this, but it is a reasonable choice. We have good contact with the people working on IBus, and they are interested in this integration work.
• Choosing IBus now does not mean we are stuck with it forever. Even though we believe that IBus is 'good enough' as a framework, and can support input method features we need, it is possible to port to another framework if IBus turns out to be a dead end. Doing the integration work now will help in clarifying what APIs/features a candidate for that will need.

How to use other IM frameworks

After this integration is done it will still be possible to use other IM frameworks in GNOME. First, there's a compile time option to build g-s-d and g-c-c without IBus support. Even if g-c-c and g-s-d were compiled with IBus support there's the option of removing ibus-daemon from the system which is enough for all the IBus functionality to be disabled. The IBus client side library can't be uninstalled in this case though but it shouldn't have any side effects.

If you don't want GNOME to touch X keyboard configuration at all it's possible to disable g-s-d's keyboard plugin with

 $ gsettings set org.gnome.settings-daemon.plugins.keyboard active false 

This means that no XKB layouts/variants/options will be set by GNOME and thus the System Settings' Input Sources will be of no use.

How to Help

Talk to Rui, Takao or Allan