GNOME and input method integration

Those of us who type in Latin characters may easily overlook what it takes to get text into windows or command lines in other writing systems. Entry of characters not found on one's keyboard requires the use of an input method (IM) which turns multiple keystrokes into characters. There are plenty of capable projects, but they often lack deep integration into the desktop environment or widget toolkit. In April, GNOME developer Rui Matos proposed a feature for the upcoming GNOME 3.6 release that would integrate the IBus framework into the core GNOME desktop, tackling this precise challenge. IBus is a framework that allows the user to select — and switch between — multiple IMs. The plan spawned considerable debate, not only on the merits of IBus, but on the wisdom of tightly integrating a single component into the desktop environment. Complicating matters is the divide between the bulk of the GNOME developer community and those users who depend on input methods, primarily from the Chinese-Japanese-Korean (CJK) language communities.

At the heart of the issue is how CJK users input text. In alphabetic or syllabic writing systems (including European, North Indic, and Middle Eastern), there is a known mapping between the pronunciation of a word and its written representation. In the logographic writing systems of CJK, where the strokes of the character do not represent sounds or other subdivisions of the word, users make use of an IM instead. There are phonetic IMs such as Pinyin (in which the user types in the romanization of a word on the keyboard and the IM substitutes the correct character, or logogram), shape-based IMs like Cangjie (which decompose the logogram in a strict order), and many hybrids. In most cases, good dictionaries or tables are required, plus word-prediction, spell-checking, and other add-on features to cope with homophones and other tricky bits. Mobile phone users got a taste of the IM experience through T9 and other numeric-keypad predictive text systems, which have largely been replaced.

For everyday typing, the challenge is greater because no one input method is inherently superior: if you do not know how to pronounce an unfamiliar word, a phonetic method is no use, and switching to shape-based method makes sense. On the other hand, typing a word that you hear but have not seen written down demands a phonetic method. Likewise, regional accents can have very different pronunciations for the same logogram, but there is often more than one way to decompose a logogram by shape — not to mention the problem of writing reforms like Simplified Chinese, which is not simplified uniformly between mainland Chinese hanzi and Japanese kanji. Thus, almost no IM can be relied upon to the exclusion of all others. Throw in open source developers' penchant for reinventing the wheel to scratch their own itches, and the result is multiple IM frameworks, each of which can load individual IMs as the user chooses.

Supporting all of these frameworks is a challenge, one that Matos (who works mostly on gnome-control-center, GNOME Shell, and other desktop components) felt detracted from GNOME's ability to provide a consistent desktop experience and left CJK users a step behind those users whose writing system works out-of-the-box. As he explained on the desktop-devel list, IM framework proliferation reduces the odds that any of the frameworks will get enough testing to be robust, and it greatly complicates bug triage for GNOME. Plus, many of the popular IM frameworks also attempt to be cross-desktop, which makes integrating them seamlessly into GNOME difficult. Their visual appearance does not match, they conflict with core GNOME settings like XKB configuration and key bindings, and they cannot be automatically started (relying either on user interaction or shell scripts to launch). The fix he proposed is to take one IM framework, tie it in more directly to GNOME (including adding or extending GNOME APIs where needed), and make sure that it works for the majority of users.

Specifically, Matos said, GNOME has three requirements to properly integrate an IM framework with the desktop: a GTK+ module, a D-Bus API that can enumerate, activate, and configure installed IMs, and a D-Bus API on GNOME's side that the framework can use to draw predictive-text pop-up windows. Right now, he said, only IBus meets all of the requirements. Owen Taylor added some additional requirements to integrate the framework with GNOME accessibility and configuration standards, and a quality set of existing IMs. The IBus team expressed a willingness to work with GNOME, which was also critical.

Feedback from the CJK community

However, the plan elicited strong reactions from some members of the CJK user community. Marguerite Su replied that few if any CJK users like IBus; with most preferring rival framework Fcitx out of the existing options available on desktop Linux. Others chimed in with criticism of IBus. The complaints included several overlapping issues, including customization features, IM engine quality, and speed. Su elaborated on the feature disparity, saying that some users want to customize shortcuts, rearrange the word-completion suggestions, or fetch new dictionary words from Internet servers. But trading IBus for Fcitx is not the simple solution. IBus works well for Simplified Chinese, but not Traditional Chinese, while Fcitx is focused largely on Chinese and has less robust support for other languages, including Japanese (although it has plans to improve its Japanese support). Chinese users are greater in number, which might argue in favor of Fcitx, but surely the best solution would be to find a framework that serves everyone. Support for writing systems unrelated to the CJK family (such as Tibetan or Thai) is weaker in general across the IM frameworks.

But over the course of the sometimes-heated list discussion, the IBus critics proposed not simply adopting Fcitx outright, but keeping IM frameworks a user-controlled, pluggable option. For example, Liang Suilong, who argued that IBus is laggy, still advocated building an "IM framework framework" for GNOME, thus allowing users to choose the framework they preferred. But that idea was not well-received by GNOME developers. Tomas Frydrych summed up the two sides of the divide:

As others pointed out on the list, the latter point was not accurate; IBus does support CJK, but not all users are happy with its IM implementations or auxiliary features. Complicating matters more is the cultural divide between the groups. Weng Xuetian pointed out that the core GNOME developers are not IM users (most speak European languages), which makes them unqualified to select the "best" IM framework to then be used by a large number GNOME users who were not able to participate in the discussion.

Frameworks, not engines

But the groundswell of IBus criticism was not the final word. Tommy He said that the debate was too focused on CJK input, to the exclusion of other writing systems, and moreover that much of the lobbying in favor of Fcitx focused on the quality of the various IM engines, rather than the frameworks themselves. After all, if Fcitx can add a new and improved Japanese IM, then IBus could add one for Traditional Chinese.

Admittedly, the framework-versus-IM debate is a difficult one to pin down. On the one hand, Fcitx proponents enjoy its more flexible plugin system, which allows user-defined macros and other daily-use features. But that same flexibility could make it more difficult to integrate with GNOME's existing language settings and preferences, when providing a better first-run experience is explicitly one of the goals. As Owen Taylor observed, Fcitx generates its configuration GUI on-the-fly, which is a technique GNOME finds problematic and tries to avoid.

On May 14, Taylor attempted to re-center the discussion to the framework question, arguing that GNOME needs to pick one framework, then make it work "as well as we can possibly make it for all users. Multiple partially working frameworks are not a substitute." When the IBus-versus-Fcitx debate briefly resurfaced, Bastien Nocera advocated starting the IBus integration work as soon as possible, then inviting Fcitx to bring its own code demonstrating that it could fit the role better. "A lot of the code should be reusable, and you can show how much more awesome and complete your favourite IMF is."

When it looked like the core GNOME developers had made their final decision to integrate IBus, a few IBus detractors asked the team to postpone the decision for further discussion, but without success. Nocera reiterated his opinion that it would be better to pick an imperfect IM framework and replace it in later releases than to do nothing:

But Jasper St. Pierre compared the decision to other components, like audio. GNOME does not attempt to support ESD and OSS in addition to PulseAudio due to limited resources, he said, and GNOME's choice of IM frameworks will not force distributions to follow suit. "I doubt we have the resources to support both IBus and FCITX, and provide a good experience for both. Individual distributions may, but that's their call, not GNOME's."

The Fcitx lobby may not be satisfied with that response, but it looks like IBus is here to stay for the 3.6 development cycle at the very least. The GNOME wiki page lists seven tracker bugs to follow the integration with GNOME Shell, GNOME control center, and other components. There is still plenty of integration and debugging work to be done, including improving IBus's support for Hong Kong localization and reducing interference with other applications.

In an email, Matos said that he thought many of the user concerns about losing Fcitx boiled down to UI/UX issues, particularly attachment to "things like skins and themes for the UI popups. In this regard I just can say that as far as gnome-shell is (somewhat) themable people will be able to do themes for gnome-shell's IM popups." On the other hand, he added, there are Fcitx features like spell-checking that should be handled desktop-wide, while features like retrieving word lists from an online service "is orthogonal and there's no reason it can't be implemented [in] IBus." It may not be an easy journey, but clearly pulling CJK users into the fold with first-order input support has potential benefits that far outweigh the costs.