libtextinput, a minimal input method framework, as a library

Lately, I’m working on a new input method framework called libtextinput. Well, actually, I was doing some experiments making ibus-daemon lighter, but later I decided to write a new one with my own design. Yes, I know I’m reinventing the wheel but the design is quite different from other frameworks:

  • It is not a session service, but a library, so it can be directly linked to a compositor, etc. The API is modelled after the Wayland input-method protocol and much simpler than other frameworks. The main difference is that there is no concept of “input context”, so clients can directly interact with IMEs.
  • While it mainly supports in-process IMEs, it also supports IMEs running as a separate process. This feature is particularly useful for heavy IMEs like Chinese Intelligent Pinyin or Japanese Kana Kanji conversion. Out-process IMEs are automatically restarted after crash.

For more details, see the overview and TiEngineManager chapters in the reference (still terse though). It is still in early development stage but a demo program has just started working:


If you are unable to play the movie with your browser, you can download it from here (WebM, 3.1MB).

4 thoughts on “libtextinput, a minimal input method framework, as a library”

  1. I just installed Xubuntu.
    I use ddskk inside emacs, but need a Japanese input method for applications such as
    libreoffice, firefox, etc.

    I see Ibus, ibus-skk, SCIM, UIM, fcitx, anthx, mozc and many other articles and am confused.

    You have a lot of experience and I want to ask you advice.
    Which japanese input method do you recommend ?

    1. Sorry, I don’t really know the recent trends of Japanese input methods. All I can say is that the IBus fallback (= non-GNOME) user interface still has rough edges.

  2. Your libtextinput has to work with a lot of IME plugins written in low level language that can easily crash, bringing down the whole host application. I’ve seen this with Windows’ Text Services Framework. Load a faulty IME and everytime I type anything, the focused app crashed immediately. In this case, it could be the compositor, which is even more annoying.

    1. IME’s written in high level languages can also easily crash, sometimes more likely unless they have enough test cases. Try search “ibus-anthy abrt” on bugzilla: http://red.ht/1qBzXMO

      Luckily, almost all major engines have already separated their core algorithms out into C libraries e.g. linpinyin, pyzy, libchewing, libzhuyin, libcangjie, libkkc, libskk, libhangul, libthai, m17n-lib. The amount of glue code won’t be such large, even if written in C.

      Another example, Chrome OS hasn’t allowed any Python code from the beginning. It used to use IBus, but never included engines written in Python.

      Also, I guess you probably didn’t read the post – libtextinput does support engines running as a separate process and even has a plan to provide a bridge between IBus engines.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>