Support input methods beside ibus

Bug #983254 reported by csslayer on 2012-04-16
This bug affects 61 people
Affects Status Importance Assigned to Milestone
Fix Released
Brandon Schaefer
Fix Committed
Brandon Schaefer
Fix Released
Brandon Schaefer
Fix Committed
Brandon Schaefer
nux (Ubuntu)
Nominated for Precise by Timo Jyrinki
unity (Ubuntu)
Nominated for Precise by Timo Jyrinki

Bug Description


The main bug that's related to 'fixing' this issue is LP: #1043627. See that bug for the most up-to-date discussion.

As 12.04 is an LTS, many users decide to stay with that version until the next LTS version is available. Many of those users require different input methods to comfortably input characters in their language. We do support IBus for some of the languages, but others are still using XIM as the input framework. Those users cannot input in their language using their standard input methods. This means using the Dash and HUD is much more troublesome or even impossible in normal cases.

We think that even though it is essentially a new feature, it can be thought that the lack of support for non-IBus additional input methods is a bug in a way.
It is a big change, but with proper testing, we would ensure that the addition does not introduce any new regressions.

Also, the change is needed by OEM. It is a big change, but it's crucial for CJK - Kyrlin has voiced the proposition to use fctix as the default input method, which _needs_ XIM support in Nux and Unity.

[Test Case]

1. Install fctix-pinyin
2. Run im-config and enable fctix as the default IM
3. Reboot your machine
4. Open the dash and input non-latin characters using fctix
   -> Non latin characters (Chinese in this case) should appear on screen.

[Regression Potential]

In an impossible scenariu, broken IBus input or input in overall in Nux input fields.
The good thing about the XIM support is that it's rather isolated, so potential breakage of the XIM code won't impact normal Nux workflow. Just XIM input might not work.

[Other Info]

The same functionality is already available in the newer Unity releases.

Original description:

As you might want to solve some problem, just because of silly unity developer don't know how to fix your silly input method bug on input method, but you guys breaks input method for so much user. In spite of ibus, there are several input method are widely used in the world, fcitx, gcin, hime, uim.

As unity developers might not know, the install input method is so hard for normal users, but they are still trying to change the default one, in order to meet theirs need.

And there are even more input method are coming for different scenario, for example Maliit for on-screen keyboard.

This is totally going backwards from Ubuntu 11.10.

So, if you want to throw all other input method away, ok, we will throw ubuntu away. Not to mention silly im-switch and im-config are still not working well.

Related bug report:

Related branches

Aron Xu (happyaron) on 2012-04-16
affects: unity → nux
Aron Xu (happyaron) wrote :

Despite the wording is tempered, I strongly support the opinion on bad input method support in Unity stack, and this report emerges because Nux depends on ibus with brute force so moved this report here.

To be frank, IME support in 12.04 LTS is nearly broken from a user's point of view, and is totally broken from an IME developer's point of view.

I have subscribed several parties, including Nux Team, CJK tester team, IME packaging team, and pitti, sabdfl. I know some of the individuals may or may not be able to deal with the case himself, but I sincerely wish this will bring the issue to your attention, that is Unity, and Ubuntu, is on the way of losing quite a few users, some action must be taken.

Aron Xu (happyaron) wrote :

If you prefer to discuss the whole story of the messy situation of IME support using email, I'd like to see someone relevant to the development of unity stack to start the conversation, so we're happy to provide our insights.

Dororo Chen (dororofish) on 2012-04-17
Changed in nux:
assignee: nobody → Dororo Chen (dororofish)
assignee: Dororo Chen (dororofish) → nobody
csslayer (wengxt) wrote :

Sorry for my initial words.

A directly solution is, nux provoides a similar plugin interface to gtk/qt im module, and make other input method can write a plugin for it. It won't take too much work for input method to implement a plugin.

Or go back to old gtk solution, which is ok but I'm not familiar with nux code, and might not be possible.

Shih-Yuan Lee (fourdollars) wrote :

The following links are not about this bug, but it may be worth to read. Traditional Chinese Edition.

csslayer (wengxt) wrote :

Shih-Yuan Lee, people will not care the thing they do not use. There is, no such good people in the world. Fine words will not solve any problem. Though this is a problem, but it can also be an opportunity to make unity to the right road. Just because Unity IS in open source world, that I would leave comment here.

I have watched unity for a long time, no body even cares about supporting input method. They just use input-method-specific-undocumented-magic-environment-variable to hack unity. So what I ask for is, fix the right thing in the right way. There are thousands applications in Linux world, which CAN works right with ANY input method. Don't make unity another wrong one.

I'm also willing to patch nux with what I said in #3, it doesn't need so much work. Or unity/nox team want any discussion on further interface, I would also provide any help as far as I can.

Yes, people are important, but please don't forget people are important, BECAUSE code are nothing without people.

V字龍(Vdragon) (vdragon) wrote :

Badly traslated article : CJK input method compatible problems software developers should avoid.

Michael (linmx0130) wrote :

there are a lot of people didn't use ibus

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nux (Ubuntu):
status: New → Confirmed
Ma Hsiao-chun (mahsiaochun) wrote :

Please note that the so-called duplicate bug (actually reported earlier) may contain useful information for developers.

Please check it!

Changed in nux:
status: New → Confirmed
Changed in unity:
status: New → Confirmed
張旭 (zx1986) wrote :


Didier Roche (didrocks) wrote :

Starting the discussion insulting developers is really not the way to go. In addition, please read the ubuntu code of conduct: and consider restate the description of the bug.

As on the actual issue, it's free software. If you provide a patch with tests and well documented/formatted code, I'm sure the nux developers will be more than happy to merge it. If you can't/don't want to develop it yourself, good news, it's free software: you can sponsor a developer to meet your need and get a patch ready that nux/unity developers can review. You will show by this way that you care enough on this issue (which it seems you do as virulent you are on the description) to commit yourself either by writing code or by sponsoring someone to do it.

Ma Hsiao-chun (mahsiaochun) wrote :

Hi, didrocks

The origin statement is actually quite clear if you remove words like "silly", "fucking". It's human nature to be a bit virulent if they see something really sucks.

Your paragraph on free software is pointless. It sounds like you don't care the hot problem at all. You just beg for code.

Didier Roche (didrocks) wrote :

@Ma: I don't believe that I said the issue isn't important by any way. However, I do believe that when I sign something as the reporter did for the CoC, I try to apply it because I believe in what I sign. This description isn't the case by any extent.

I don't think the paragraph on free software is pointless. It just shows that if the problem is that much important to reveal so virulent words and so many reactions, there are many ways for any of impacted people to get the problem fixed, as being an actor, not just acting like a consumer.

On Thu, Apr 19, 2012 at 3:47 PM, Didier Roche <email address hidden> wrote:
> @Ma: I don't believe that I said the issue isn't important by any way.
> However, I do believe that when I sign something as the reporter did for
> the CoC, I try to apply it because I believe in what I sign. This
> description isn't the case by any extent.
> I don't think the paragraph on free software is pointless. It just shows
> that if the problem is that much important to reveal so virulent words
> and so many reactions, there are many ways for any of impacted people to
> get the problem fixed, as being an actor, not just acting like a
> consumer.
I noticed that you are a staff of Canonical, then why cannot you treat users
as consumers?
> --
> You received this bug notification because you are a member of IME
> Packaging Team, which is subscribed to the bug report.
> Title:
>  Unity use ibus explicitly, make it impossible to use other input
>  method
> Status in Nux:
>  Confirmed
> Status in Unity:
>  Confirmed
> Status in “nux” package in Ubuntu:
>  Confirmed
> Bug description:
>  As you might want to solve some problem, just because of silly unity
>  developer don't know how to fix your silly input method bug on input
>  method, but you guys breaks  input method for so much user. In spite
>  of ibus, there are several input method are widely used in the world,
>  fcitx, gcin, hime, uim.
>  As you fucking unity developers might not know, though install input
>  method is so hard for normal users, but they are still trying to
>  change the default one, in order to meet theirs need.
>  And there are even more input method are coming for different
>  scenario, for example Maliit for on-screen keyboard.
>  This is totally going backwards from Ubuntu 11.10.
>  So, if you want to throw all other input method away, ok, we will
>  throw ubuntu away. Not to mention silly im-switch and im-config are
>  still not working well.
>  Related bug report:
>  HIME:
> To manage notifications about this bug go to:

YunQiang Su

@YunQiang: because besides being lucky and working at canonical, I first feel myself as an ubuntu member and being part of the community first. I was a benevole contributor for more than 5 years before joining canonical and I still consider having the same view since I work here.
Working for one of the sponsor of ubuntu doesn't change anything and I will certainly not treat user as consumer, as it's not my view of what a free software project is. ubuntu is "I am what I am because of who we all are". We shouldn't forget it and I see no consumer/client paradigm on this.

Anyway, I made my point on this thread and gave my advice.

Ma Hsiao-chun (mahsiaochun) wrote :

@Didier Roche I haven't signed CoC. I'm not familiar with it. Maybe you do take it seriously.

For the problem itself, I'd point out that some people still hope that this problem can be fixed before the release of new 12.04 LTS. That's why people come here and help increase heat. It is quite hard to do SRU, right? As an Ubuntu advocate, I do hope Ubuntu, especially LTS, can be almost bug-free. High quality free software is much easier to promote. Even if people later discover some hacks to work around this bug, it is still very hard to widely spread such work arounds.

If this bug cannot be fixed in a short time, then we can wait and see whether any interested developers inside or outside Canonical come.

Ray Wang (raywang) wrote :

Looks like this discussion goes like in this[1] way, and guys, please follow CoC as we are in the community.

I understand the code will affect lots of people, but virulent words will help nothing. Please respect the developers as they are volunteers, and get back to the topic, thanks in advance.


csslayer (wengxt) wrote :

I'm not even user of ubuntu, but hey, what will user do when they found app A and app B cannot work together? Obviously they will stick to either A or B which is important for them. So this time is ubuntu might cause us lose user, and it's not even our fault! This is what I'm angry about, and that's why I'm here.

From general point, who break it, who'd take response to fix it.

Anyway, I'm looking forward for some nux developers technical point on this.
1. Do nux need an extra plugin system for input method?
2. If so, what interface is needed? I can already seen there are some problems even with ibus.

Actually clutter have similar problem, but gnome guy use gtk-im-module inside gnome-shell's st library, so gnome-shell can work with all existing input method without problem.

A part on agreeing with didrocks on everything, I think that if you really want to get involved to fix this, you only have to join #ubuntu-unity on freenode, and *talk* (not offending!) with developers (both jaytaoko and bschaefer can help) about the best way to get this fixed.

If you want to help in this with code, I think that you should check the TextEntry nux class, and provide for it a different IME method.

Changed in unity:
importance: Undecided → Medium
Ma Hsiao-chun (mahsiaochun) wrote :

I've changed my mind a little bit.

Yes, some input methods (engines) in IBus sucks, seriously.
Built-in input methods in Mac OS X or Windows sucks too.
However, third-party input methods on Mac OS X or Windows would never ask users to replace input method framework in the system.

I think ibus-fcitx, ibus-gcin, ibus-hime, ibus-uim, ... would be the best way of publish alternative input methods on Ubuntu.
Tight dependency on one particular input methods framework could make things easier.

lilydjwg (lilydjwg) wrote :

@Ma Xiaojun: Yes, most IMs on Win/Mac won't replace the IMF; it is because they themselves aren't one. And I think an IM on Win call "万能五笔" which is independent from the system's IM framework.

And, I don't think it is a must for an IMF to ask the user before they replace some part of the system.

Ma Hsiao-chun (mahsiaochun) wrote :

Thank you for pointing out "万能五笔" (Omnipotent Wubi).
It has both "EXE外挂版" (EXE plugin version) and "IME内置版" (IME built-in version).
"EXE外挂版" has its own advantages as well as odds (as documented in the website).
And "IME内置版" won't lose all the goodies about "万能五笔".

For Ubuntu, using ibus-fcitx for a while don't prevent a user to switch to Fcitx completely later.

I've skimmed through the diff of the two "Related branches". It seems that you are adding Fcitx in parallel to IBus. So that GCIN, HIME, UIM would still be unusable under nux. Though I personally advocate that alternative IMFs provide IBus frontends. I would like to see patches that make nux independent of IBus rather than patches that add dependency to yet another IMF.

Andrea Azzarone (azzar1) on 2012-07-10
Changed in nux (Ubuntu):
status: Confirmed → In Progress
Changed in nux:
status: Confirmed → In Progress
csslayer (wengxt) wrote :

@Ma Xiaojun
No, things like ibus-fcitx will at least break fcitx, such idea will also break hime, saying so only show you don't know fcitx nor hime nor other IMF (maybe including ibus). It will lost consistency and if user switch to fcitx, nux will still not be able to use other im.

It will not introduce extra dependency if it's build in a modularized way.

The existing XIM patch, IMHO should be ported to my patch way. Thus it will also be able to support future wayland protocol.

Ma Hsiao-chun (mahsiaochun) wrote :

I won't reply "I know better" argument.

For the patch:

I know it has some dynamic in the run-time.
However, FcitxIMEContext, IBusIMEContext and IMEContextFactory are fixed in compile-time.
I don't think you can add HIME support in the run-time.
Instead, you have to add HimeIMEContext class, modify IMEContextFactory and compile the code again.

V字龍(Vdragon) (vdragon) wrote :

@Ma Xiaojun
Implementation will be better than comment... thanks.

Yu Ning (yuningdodo) wrote :

Hi @Henry Lin,

I was studying on this bug these days, and personally I support the XIM way ( for this, because it could be an universal solution. However input methods, HIME for example, still won't got worked without XIM support themselves. So I want to check if it could be possible for HIME to add XIM support.

V字龍(Vdragon) (vdragon) wrote :

@Yu Ning
according to ,
 * Supports GTK2+/GTK3+/QT3/QT4 im-module and XIM.

If HIME need a patch or something please file an issue here:

Yu Ning (yuningdodo) wrote :

Hi @Henry Lin,

Thank you for the information you provided, I will check that.

csslayer (wengxt) wrote :

@Yu Ning
Hi, I'm working on porting your patch to make it use a unified way as InputMethod class. You can take a look a my merge request, though that's for fcitx only currently, but I'm working on xim support in that style. Current XIM support looks a little bit hack.

And still xim is not a very good solution (For reason we all know), if hime side can provide a patch, I think that would be better.


Yu Ning (yuningdodo) wrote :

Hi, before I actually work on something I did had compared your branch and paulliu', and my first attempt is to merge paulliu's XIM patch to your branch, to provide InputMethodXim. However I failed to do that. The problem was I didn't found some proper way to handle events. But I think I could try this again, and hope I can managed it this time.

Any way, I think it is not a perfect idea to write a InputMethodXxx for each IM, neither to add support inside each IM for nux's input method interface. Both ways have a problem, that even if we add support for N input methods, the user may want to use a (N+1)th one.

So in my personal opinion, to support the currently most widely used IM protocols, XIM, GtkIMContext, QT..., should be a lazy but acceptable way, almost every input method support at least one of them. However it may be impossible, or at least hard, to support gtk/qt, because we never know if a nux window is a GdkWindow, QWindow, or just a raw nux window.

However I support your solution on split nux's input method to an interface with some implements. It did looks hacky & strange on current ibus support or xim support.

summary: - Unity use ibus explicitly, make it impossible to use other input method
+ Support input methods beside ibus
ZhengPeng Hou (zhengpeng-hou) wrote :

for those who is still interested in this topic, I'm proposing a session at this time UDS to discuss it.

Ma Jun (maclin.jun) on 2012-11-21
Changed in nux:
status: In Progress → Invalid
Changed in nux:
status: Invalid → In Progress
Changed in nux:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nux - 4.0.0daily12.12.05-0ubuntu1

nux (4.0.0daily12.12.05-0ubuntu1) raring; urgency=low

  [ Michael Terry ]
  * debian/control:
    - Update Vcs-Bzr
    - Build-Depend on dh-autoreconf and gnome-common
  * debian/rules:
    - Use dh_autoreconf
    - Enable headless tests during build
  * Switch to dh9 and multiarch
  * Automatic snapshot from revision 700 (bootstrap)
    - Fix crash when lift clicking after right clicking (LP: #1057809)
    - Fix crash on amd64 from an invalid cast (LP: #1052765)
    - Fix a couple crashes in example code (LP: #1064918)
    - Fix dash and launcher being all black (LP: #1067860)
    - Fix launcher dragging the wrong way (LP: #1057995)
    - Only load textures once they are needed (LP: #816692)
    - Add pointer checks for invalid cached textures (LP: #1066788)
    - Fix some FTBFS's on armhf (LP: #1065293, LP: #1067081)
    - Fix a bunch of compile warnings (LP: #1056633)
    - Removed some unused code (LP: #937583)

  [ Didier Roche ]
  * Transition packaging to Nux 4.0
  * Add split mode for daily build

  [ Ricardo Salveti de Araujo ]
  * Doesn't need to depend on gcc 4.6 anymore (LP: #1044836)
  * make check-headless should respect DEB_BUILD_OPTIONS=nocheck
  * Does not need to be built with gcc 4.6 anymore (LP: #1044836)

  [ Ying-Chun Liu (PaulLiu) ]
  * Unable to use H.I.M.E. input method in the Unity search bar( & HUD
    also) in Ubuntu 12.04LTS | 無法於Ubuntu 12.04LTS的Unity
    searchbar(以及HUD)使用H.I.M.E.輸入法 (LP: #973808)
  * Support input methods beside ibus (LP: #983254)

  [ Automatic PS uploader ]
  * Automatic snapshot from revision 727
 -- Automatic PS uploader <email address hidden> Wed, 05 Dec 2012 09:27:01 +0000

Changed in nux (Ubuntu):
status: In Progress → Fix Released
V字龍(Vdragon) (vdragon) wrote :

I'm curious about the status of this bug report, currently(12/24 on Ubuntu 12.04) there still no support for HIME input method for entering Chinese character on Unity search bar.
Is this fix being ported to quantal-updates?
Sorry for any annoyance.

V字龍(Vdragon) (vdragon) wrote :

(12/24 on Ubuntu 12.04) -> (12/24 on Ubuntu 12.10)
sorry for that.


Looks like the fix for unity hasn't been released yet, but it has been fixed :). (Though the preedit isn't perfect)

Changed in nux:
milestone: none → 4.0
Debra Virden (teddydlv) on 2013-02-06
description: updated
Changed in unity:
status: Confirmed → Fix Committed
assignee: nobody → Brandon Schaefer (brandontschaefer)
Changed in nux:
assignee: nobody → Brandon Schaefer (brandontschaefer)
Changed in unity:
milestone: none → 7.0.0
Changed in nux:
importance: Undecided → High
Changed in unity:
importance: Medium → High
Stephen M. Webb (bregma) wrote :

Fix Released in Unity Unity 7.0.0 "R series".

Changed in unity:
status: Fix Committed → Fix Released
V字龍(Vdragon) (vdragon) wrote :

@Mark Shuttleworth
Off topic...but I think it's quite worth to mention that if Unity chooses to abandon configurable panel application icon whitelist settings it will be a great impact on input methods(which needs icon(s) to show itself's status, but not all imput methods have implemented an appindicator-based icon yet) and will certainly bring great burden to at least a big part of CJK users.

At least from zh_TW, ibus is far from stable(at least, till 12.10), very outdated, and is also very different logic to use than the input method in Windows. Users will likely tried to switch to another input methods such as gcin/HIME(much popularity in zh_TW), fcitx or scim etc. and may found it quite useless as the icons are blocked by the shell itself. A desktop environment unable to let user input their language easily is valueless no matter it looks beautiful or not. This reminds me the bug #876722 that LibreOffice will crash immediately after input over 6 Han characters...its a disaster.

Bug #876722 reproduce video - YouTube

Thanks for reading ;)

Aron Xu (happyaron) wrote :

Just FYI, Fcitx in Raring has provided decent indicator support, which worth a try.

V字龍(Vdragon) (vdragon) wrote :

@Aron Xu
TksFYI, however according to my & friend's recent experience(12.10), fcitx is not quite having the basic requirements of zh_TW input

Ma Hsiao-chun (mahsiaochun) wrote :


Please try latest Fcitx 4.2.7 (you can do this by using Raring) and
let people know your concerns (use issue tracker [1], mailing lists
[2, 3], whatever).


V字龍(Vdragon) (vdragon) wrote :

@Ma Xiaojun
fcitx works almost great in raring(unless while I got nothing workable in quantal(I can't even activate it)

Current status in Unity(for chewing IM)
ibus - pretty buggy with indicator
HIME - great (with icon whitelist patched), still affected by this bug
scim - Not working at all
fcitx - Not working at all

ibus - perfect(?) with indicator
HIME - this bug fixed however no more whitelist to show icon
scim - not tested
fcitx - nearly perfect with indicator

V字龍(Vdragon) (vdragon) wrote :


HIME - indicator working : ) (with semi-official PPA)
scim - no icon, find no way to enable chewing
gcin - seems supported with official PPA

wei qiu (wei) wrote :

Does it mean that compliation of nux also doesn't depend on ibus any more?

Stephen M. Webb (bregma) wrote :

Fix Released in Nux Nux 4.0.0.

Changed in nux:
status: Fix Committed → Fix Released
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
description: updated

It appears there is no hope to use ibus for kannada lang(one of the Indic). whereas previous versions were working fine only to day I am experiencing great difficult. How long I hve to wait for solution?

V字龍(Vdragon) (vdragon) wrote :


79yrs. Just joking ; )

If there's no input method of your language based on ibus you can try other desktop environment besides Unity(KDE, XFCE, etc.) as a workaround.

Stephen M. Webb (bregma) wrote :


You will probably need to install the ibus-m17n package to be able to use Indic input methods. If this is a new requirement dues to the use of ibus, the localization dependencies should be ironed out by the time Saucy Salamander is released.

To install the package, open a terminal and type "sudo apt-get install ibus-m17n" to install the package. You will probably ned to log out and back in to force the ibus daemon to refresh its configuration, and ten you can use the ibus-setup utility to select your favoured input engine.

Changed in unity (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.