This spec is about ibus integration and improvement for Jaunty and beyond.

Release Note



Since we have many problems with SCIM and SCIM is not actively developed upstream anymore, it would be nice to have a replacement. Ibus is such a replacement candidate.

Use Cases

  • Ming is a Chinese user. He known nothing about Ubuntu, insert a LiveCD, chooses his language on the CD boot screen and install Ubuntu on his computer. Both on the Live CD and after install, he can change the input method to one more suited to his tastes, and it works on any application;
  • Karl have been using Ubuntu for a while, and while on a German session is using SCIM to write in Korean. He upgrades his distribution one day and can keep writing in Korean without having to learn another method. While writing in German with or without using ibus, deadkeys still work;
  • John has never understood why he could input a CJK language in most programs, but never in KDE 3 or 4 applications. Wine applications were a hit-and-miss. He upgrades one day and without apparent changes he can now do so;
  • Rachel is using Xubuntu, and needs to edit some Japanese documents. She enable Japanese support, and can use it in Abiword, Kate and Photoshop under Wine;
  • Lucie has always found awkward that she had to enable a special ubuntu-ja repository to get good Japanese input in Ubuntu. She installs a new version one day and is happy she doesn't have to go through that trouble anymore;
  • Keyboard layout: en_US
  • Keyboard layout: en_GB (and other en_*)
  • Keyboard layout: european (non en_*) without dead keys
  • Keyboard layout: european (non en_*) with dead keys
  • Keyboard layout: dvorak
  • Keyboard layout: non-latin


It is assumed that ibus can be a drop-in replacement for SCIM.


Ibus is a client / server application. The server handles the string conversions, while the client talks to the applications and interacts with the user. Frontends for GTK+ and QT4 are available. Input Method Engines (IME) get loaded as modules. In contrast to SCIM, which loads all modules at startup time and needs to be restarted when the configuration changes, ibus loads the modules dynamically and does not need to be restarted when the configuration gets changed.


UI Changes

  • modify menu so that only one mouse button is needed (on mobile devices we have only one mouse button)
  • add on-screen keyboard for mobile devices
  • improve hotkey configuration for the IMEs

Code Changes

  • port the code from python to C (work in progress)
  • need frontend for KDE (probably not in Jaunty)
    • configuration
    • GUI
    • based on QtDBus.


  • packages will be available in universe
  • ask the community to help testing
  • if test results are satisfactiory, push ibus into main and replace scim (might not happen in Jaunty)
  • the usage of ibus is similar to scim, so users don't need to learn much new

Test/Demo Plan

  • test all the use cases
  • go through the reported SCIM bugs and test if any would also apply to ibus (if yes, they might only be fixable with the outstanding architechture redesign.

Outstanding Issues

Future work:

  • architecture redesign (involves X.org, kernel, framebuffer)
    • one user space service, which takes care of keyboard layouts and IMEs
      • XKB and IMEs handled by the same service for any application
      • IMEs as modules
      • hook into input layer of X.org
      • get keysyms from kernel and handle keyboard layouts
    • (GUI) frontend communicates with user and applications for IMEs
      • communicates over dbus with user space backend
  • one library for each language, which contains wordlists, engines and keyboard mappings, which can be shared by all IM frameworks available.

Debian ITP:


UDSJaunty/ibus-spec (last edited 2008-12-25 16:18:30 by ZG015126)