Status: Implementation in progress
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.
gnome-shell, control-center, libgnomekbd, ibus, Takao Fujiwara, Allan Day
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 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
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