Support input methods beside ibus

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.

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.

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.

The following links are not about this bug, but it may be worth to read.
http://allisonrandal.com/2012/04/15/open-source-enlightenment/
https://gist.github.com/2400315 Traditional Chinese Edition.

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.

Badly traslated article : CJK input method compatible problems software developers should avoid.
https://docs.google.com/document/d/1HB3juffu0KgSUyg15y8hBZOLcJdHK9KDVPFyCwqHh-I/edit

there are a lot of people didn't use ibus

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

Please note that the so-called duplicate bug (actually reported earlier) may contain useful information for developers.
https://bugs.launchpad.net/bugs/973808

Please check it!

I DO NOT WANT TO USE ibus!

Starting the discussion insulting developers is really not the way to go. In addition, please read the ubuntu code of conduct: http://www.ubuntu.com/project/about-ubuntu/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.

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.

@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.
> https://bugs.launchpad.net/bugs/983254
>
> 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: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/973808
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nux/+bug/983254/+subscriptions

--
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.

@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.

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.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=656680

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.

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.

@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.

@missyou11
Thank you for pointing out "万能五笔" (Omnipotent Wubi).
http://www.wnwb.com/
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.

@csslayer
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.

@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.

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

For the patch:
https://code.launchpad.net/~wengxt/nux/fcitx-support/+merge/114085/+preview-diff/+files/preview.diff

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.

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

Hi @Henry Lin,

I was studying on this bug these days, and personally I support the XIM way (https://code.launchpad.net/~paulliu/nux/nux/+merge/106875) 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.

@Yu Ning
Hi,
according to http://hime.luna.com.tw ,
FEATURES:
 * Supports GTK2+/GTK3+/QT3/QT4 im-module and XIM.

If HIME need a patch or something please file an issue here:
https://github.com/caleb-/hime/issues

Hi @Henry Lin,

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

@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.

Comments?

@csslayer
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.

for those who is still interested in this topic, I'm proposing a session at this time UDS to discuss it.
https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-input-method-improvement

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

Hi,
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.

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

@Henry

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

https://bugs.launchpad.net/unity/+bug/1086988

Thank you, Debra.

Fix Released in Unity Unity 7.0.0 "R series".

@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
http://www.youtube.com/watch?v=sxj_3G-THOo

Thanks for reading ;)

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

@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

@Vdragon

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).

1. https://code.google.com/p/fcitx/issues/list
2. https://groups.google.com/group/fcitx
3. https://groups.google.com/group/fcitx-dev

@Ma Xiaojun
Hi,
fcitx works almost great in raring(unless http://code.google.com/p/fcitx/issues/detail?id=680) while I got nothing workable in quantal(I can't even activate it)

Current status in Unity(for chewing IM)
==================
quantal(12.10)
-------------------------
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

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

UPDATE

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

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

Fix Released in Nux Nux 4.0.0.

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

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/983254

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?

@sriranga

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.

@srirange(79yrs)

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.