Unity causes ibus to not work correctly (spaces incorrectly placed)

Subscribed Brandon Schaefer to this bug report as I believe he works on the iBus related stuff.

Thank you for letting me know about this. The problem seems to lie when you hit space to end the preedit and it is committing the space before the Koren. Will take a look into this.

Does anybody know of a work-around in the meantime?

@Yubin, setting IBUS_ENABLE_SYNC_MODE to 0 is a workaround that fix wrong behaviour with some applications.

Sorry, forgot to update this report. That is the proper fix for other application, but it wont fix unity dash because with out the sync mode ibus doesn't handle regular text. Here is the bug report form upstream.

http://code.google.com/p/ibus/issues/detail?id=1291

So I've been trying to unset IBUS_ENABLE_SYNC_MODE in a Unity session by placing it in various places including .profile, /etc/environment, .bashrc, /etc/X11/Xsession.d, but I think this is being overwritten by a later command.

Does anybody know where Unity sets this particular environment variable? I'd really like to avoid modifying every single app launcher to unset the variable before starting the app.

@Yubin it is in IMTextEntry.cpp:
http://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/plugins/unityshell/src/IMTextEntry.cpp#L49

So if you start the dash it sets the env var, then close it and unset the env var.

Until Unity is made alright by whatever means to work with applications, the best bet is to still use IBUS with a little extra care. Some use the term "pre-edit" and I would like to use the term "key sequence". When a key sequence has not yet ended the screen display has an underscore covering those characters which are grouped. At this point if you type a <space> or start a fresh key sequence it will create the problem. To avoid this terminate the key sequence by pressing any of the arrow keys or the end key which will not cause any movement of cursor location; it will be taken as a key stroke required to terminate the key stroke.

For example, Rama<space> prints "Rma a" in LibreOffice, not in this window in which I am working! It becomes correctly printed if the sequence "Ra" is followed by arrow key (to remove the underscore in a) and ma again is followed by cursor key (to remove the underscore in a) and then the space. Please try other key combinations also. This is perhaps not the problem of Unity only. It is in combination with an application like LibreOffice.

Try: "It is not a very good idea." which types "Ti si not avery good die a ." Not a problem with space only in LibreOffice.

I followed Alex's instructions https://bugs.launchpad.net/ubuntu/+source/ibus-hangul/+bug/840823/comments/25 and it seemed to work fine at first (It worked after re-starting though. Logout wasn't enough).

Unfortunately, the problems were not really solved. Later I checked it again and found that it sometimes doesn't work. I could eventually found the condition causing it.
If I open any application and close it, the problems happen again.

For instance, it works fine on gedit then I close all the gedit windows and open it again. Now all the problems are back. It doesn't matter what application I open and close. Even opening nautilus and closing it causes the problem. Once it's done, it happens in any applications until I log out and in again.

So if I open nautilus and close the nautilus window, the problems start happening in gedit, terminal, Pidgin, LibreOffice, etc.

I'm seriously considering reinstalling Ubuntu 11.04.

By the way, it's not only a spacing issue. Please check out the comment I posted on the bug#840823 before
Comment:
https://bugs.launchpad.net/ubuntu/+source/ibus-hangul/+bug/840823/comments/9

The title on https://bugzilla.redhat.com/show_bug.cgi?id=753781 suggest that it's a XIM issue?

The redhat patch got commited upstream there:
http://codereview.appspot.com/5417044

The comments on bug #840823 don't confirm that the patch is enough to fix the issue though

As I said in the comment #10, I do still have some issue even with the patch. Does anyone have the same problem as mine?

Dear Kevin,

At

 https://bugs.launchpad.net/ubuntu/+source/unity/+bug/840823/comments/40

you said that you thought the problem was unique to Unity. It isn't. I've had the garbled iBus input with three machines running gnome-shell.

At first, I used Unity. Then this iBus problem became unbearable, and I started to look around for a solution. Then some people said it wasn't there in gnome-shell, so I moved over, and the thing seemed cured. But it wasn't, and started to reassert itself even in gnome-shell sessions.

Finally, the patched iBus 1.4.0 mentioned here:

  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/840823/comments/25

seems to fix the problem. I say "seems" because this is such an elusive bug, and although my systems seem to be okay at the moment, I wouldn't be totally surprised if I had problems again.

In my opinion, this is a bug in iBus, not Unity.

Best,
Dominik

This bug was fixed in the package ibus - 1.4.0-1ubuntu3

---------------
ibus (1.4.0-1ubuntu3) precise; urgency=low

  * debian/patches/git_fix_async_key_events.patch:
    - upstream git patch to fix some input issues in korean and some other
      languages where entering a character and space leads to misplaced space
      (lp: #880876)
 -- Sebastien Bacher <email address hidden> Fri, 16 Dec 2011 15:45:54 +0100

Ok, I've backported the upstream fix to precise, it would be nice to get it tested on that version, if the fix works fine we can probably backport it to oneiric next

So Dominik, do you have the problem like mine described https://bugs.launchpad.net/ubuntu/+source/ibus-hangul/+bug/840823/comments/34 in GNOME Shell?
What I don't get is that you said you don't have it https://bugs.launchpad.net/ubuntu/+source/ibus-hangul/+bug/840823/comments/36 and also said you're using GNOME Shell.

My comment about Unity is solely related to https://bugs.launchpad.net/ubuntu/+source/ibus-hangul/+bug/840823/comments/34
Even though I use the patched 1.4, I do still have the problem, and it happens after I open and close any application. If I open many applications and never close any until I log out or shutdown, iBus works fine.

Isn't there anyone having the same issue as mine at all?

No, I don't have your 840823/#34 problem, i.e., opening and closing an application -> problem. I can open and close, and things remain fine.

But yes, I'm using gnome-shell, not unity. So I am not talking about exactly the same conditions as you.

I don't want to test unity right now, because my gnome-shell + ibus 1.4.0 is working well, and I don't want to upset the applecart.

Best,
Dominik

@seb128 I'm testing Precise with the standard Unity desktop and i'm sorry to say the bug is still present :(

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

What you say, David (#19) is very depressing.

This bug means that a large proportion of Asian users of Ubuntu's flagship product CAN'T WRITE. This is major.

Surely the bug should be getting very high priority treatment. It is most regrettable that 11.10 pre-testing didn't reveal it months ago, but after October it should have been definitively fixed within a very short time.

Now that we have a fix, there is absolutely no excuse for not including it in Precise. If it persists when Precise is released, I really think we should make a fuss.

Dominik

http://www.madurax86.com/ibus-unprocessed

looks like this has the fix

does the "has the fix" url has a different fix than http://launchpadlibrarian.net/87652650/ibus_1.4.0-1ubuntu2_1.4.0-1ubuntu3.diff.gz ?

@seb128 I Installed the fixed version of the ibus and it fixes the problem for me. Here is a screenshot of both versions. The first half is the fix and second half is the current ibus.

Fixed Version:
https://github.com/fujiwarat/ibus

Both pictures follow these steps:
print env var
type in Koren press space
type in Koren press return

Also since the git version fixes this bug that means this is an upstream problem and no code in unity will have to change for this fix.

@Brandon This git version is already on Precise?

@David I'm not sure, since I have been manually patching it to test.

Bad news about that patch being an overall fix.

The patch fixes the problem if you are using XIM as the main IM; if you look at what is being patched it is specifically for XIM in the "ibus/client/x11/main.c". The problem is still there with unity because it uses the "ibus/client/gtk2/ibusimcontext.c" to handle the text. So if you use ibus through XIM the problem is fixed.

So this patch will fix ALL programs expect the unity dash if you use ibus through XIM; but if you use ibus the problem will still be there because of the env var set by unity.

This bug is still in ibus and not unity because you can re create this problem in GNOME or unity 2d. Still a useful patch as it is making progress on the problem! The unity dash still has this bug (since XIM doesn't work correctly in the dash either....)

@Brandon Thanks for your response.

I have the feeling that ibus developers are not giving enough attention to this bug. I mean, we CANNOT write properly, since October, when this bug was reported. Isn't that critical enough :( ?

On 28 December 2011, I wrote to Mark Shuttleworth about this bug. I noted that since Oneiric, Asian language users cannot type. It's a crazy situation. I said this bug should be very highly prioritized, or else the Precise release should be documented as not being for use by Asian users. I referred to this site,
  https://bugs.launchpad.net/ubuntu/oneiric/+source/ibus/+bug/880876
as the main bug report.

I got this reply from his secretary Claire Newman on 9 Jan 2012 saying,

  Dear Dominik,
  Thank you for your email to Mark regarding the problem with IBus in Ubuntu.
  It is extremely useful feedback which I have passed on to the relevant people in Canonical who will help to rectify the issue.
  Thank you for your support and for letting us know of the problem and happy new year.
  Kind regards,
  Claire

Now, I *know* this isn't the proper route for getting things fixed in Linux. It's all launchpad/git/bug reports/collaboration, etc. But like David Gómez, I think this problem is very important indeed. Critical. Whoever heard of an operating system where ordinary users can't type properly? It's crazy. And I think it has the potential to blow up in Ubuntu's face. If reviewers get hold of this issue and start posting widely on the net that it has not been possible to type Asian languages for four months or more, it could look very bad for the whole Ubuntu enterprise.

If what Claire Newman says is true, then I hope that in addition to our bottom-up efforts to move things along, there may be a top-down effort too. If they took my email seriously.

Best,
Dominik

@Dominik Yep, i agree completely with you. In software development terms, it's a critical bug. In practical terms, is just crazy to have a bug like this not fixed in three months. Hope you email made Canonical realize this bug importance.

You know, in fact i'm using Precise right now. I had other issues, but i think this bug is the one reason that made me upgrade to the development version. Not that i wanted though..., this is my only computer and i use it for work. But for my work i need to write in Korean. No luck yet :(

I do, in fact, have a working system. I typed some Sanskrit and Greek earlier this morning, with no problem. I'm on 11.10 Oneiric, and gnome-shell (not Unity, probably because of the XIM issue recently mentioned). I described what I did to get a working system here:

  http://cikitsa.blogspot.com/2012/01/ibus-bug-fix.html

I have applied this to two installations, a desktop and a laptop, both with gnome-shell, and ibus+m17n is working on both.

I had to compile the deb files using Alex Lee's instructions separately on each machine (the debs produced appeared to be specific to the machine I compiled on). But I feel the situation is fragile; I'm still seeing some very occasional corruption in situations I can't properly define (Java applications?).

Best,
Dominik

gnome-shell is not an option for me, bugs in ATI drivers make it unusable.

I apologies that this is taking so long to fix! It also doesn't look like the ibus developers are going to take this as a high priority bug. I started looking though the source code, so I am hoping I can find a fix soon!

Also more to the bug. If you use any keys on the number pad it will commit those before the preedit. Or F2 + number. Example: F2+3 will look like "ab3c" (if abc are Koren chars). Will cause the same problem as the space.

So some good new on progress. I found out how to get the space to work correctly, which seems to be the biggest problem with this bug. The problem looks like it is in libhangul.

The problem seems to be that when IBUS_ENABLE_SYNC_MODE is enabled it pushes all the events through the im engine (such as ibus-hangul) and since it normally only handles Koren text it doesn't know what to do when, say a space is sent through, so it says it didn't handle that space event which then IBus handles it and commits that space BEFORE the preedit. That is why the number pad causes the same problem; ibus-hangul cant handle that. Also return/enter cause the problem. (Haven't found any others, but there could be more!!)

Right now I only have the space fixed because there is a spot for it in "libhangul/hangul/hangulkeyboard.h"; which it is set to 0x0000, and changing that to what the space is hex wise 0x0020 (32 for ascii) allows for ibus hangul to handle the space. It is going to be trickier for the return/enter and num pad since those are not in the array. (Ill have to dig more into the source)

So that is the update so far. Hopefully more soon to come.

Brandon, the problem exists outside of libhangul as well, as I have this problem attempting to use ibus to type Esperanto through the m17n library.

@Brandon Wow, thanks! Glad to heard that you spotted some of the problems in libhangul

I can confirm what rnsmith2 says in #36: I have had all the ibus/m17n input problems, but I don't have libhangul loaded. See attached graphic.

For reference, the bug is on the radar for the next Unity release now.

Seems I can get a fair way to making this (at least look like) it works with some changes in Unity code, at least from my testing in Precise. Now the problem I'm facing is "just" that I seem to be getting the right behavior in the search bar despite keeping IBUS_ENABLE_SYNC_MODE enabled, but applications get started with that variable enabled as well, which I think shouldn't be the case.

For the purposes of testing this properly with other languages than Korean/hangul IBUS input; could you people please include the name of the input method you use that appear to not work, and if possible also the package I need to install to make that available?

m17n

On 28 January 2012 07:13, Mathieu Trudel-Lapierre <email address hidden>wrote:

>
> For the purposes of testing this properly with other languages than
> Korean/hangul IBUS input; could you people please include the name of
> the input method you use that appear to not work, and if possible also
> the package I need to install to make that available?
>

But see the recent comments of fujiwarat, who has (completely?) solved this
problem. As I understand it, we just need the fujiwarat patches to make
their way into the release versions of ibus.

Dominik

Hoping to add a useful feedback:
Logging in with Unity 2D will make the problem go away.

@Jihwan Song and others:
You're right. The problem only occurs when I'm logged in in Unity 3D. I've tested it Unity 2D, Gnome shell, KDE and XFCE.

This is indeed a very critical bug. I'm working on developing an ibus input engine for bengali language. After banging on two days i come to this conclusion,

1. This happens *only* with unity, at least in Oneiric. All is well in Oneiric with gnome-shell.
2. debian/patches/git_fix_async_key_events.patch doesn't fully solve the issue, after a restart, it seems to work fine, but after opening and closing some app, bug reappears. I tested with ibus (1.4.0-1ubuntu3) compiled in Oneiric.

As my understanding from reading the comments above, the bug happens when IBUS_ENABLE_SYNC_MODE is set. Disabling IBUS_ENABLE_SYNC_MODE makes all ibus work fine in all apps expect unity search bar. So as far as i understand, why it is solely needed to have IBUS_ENABLE_SYNC_MODE ?

When all apps can ibus work correctly without IBUS_ENABLE_SYNC_MODE, Will it not a good decision to make unity work without it ?
I think unity developers should make unity search bar work without IBUS_ENABLE_SYNC_MODE, then remove the setting of IBUS_ENABLE_SYNC_MODE from unity.

I test with several environment.
Please see http://code.google.com/p/ibus/issues/detail?id=1291#c11 .
The reason I didn't test with Kubuntu is I can't set ibus at latest Kubuntu.
(actuailly this bug is in kubuntu/xubuntu/lubuntu oneiric, too)

@Brandon, is it really impossible to noet set IBUS_ENABLE_SYNC_MODE?
Even ibus developers recommend not using it and Unity2D can get search string without set this env.

@Sarim, try with X Input Method.
Open gedit, right click, input method -> X Input Method

@Jinkyu Yi,
I recompiled ibus with a little hack, i changes the setting name IBUS_ENABLE_SYNC_MODE to IBUS_ENABLE_SYNC_MODE_NEW. ha ha, this makes ibus not use sync mode all the time. All other apps work fine , but i can't write anything in unity search bar, if i right click in unity search bar and set input method -> None, then i can write.

Your tip worked, the bug seems to be fixed when i select (X input Method) xim. That means the bug is in gtk immodule (client/gtk2/ibusimcontext.c)

There's some chance that my comment may be unrelated to the originally reported bug but it appears at least to me related so I add this bug as a comment here.

I realized that, while I use KDevelop, combined key stroke such as Ctrl+Alt+F may cause a window that is popped up as a result of such a key stroke not responsive to further key stroke. Funny thing is Alt+F4 still works to close the pop-up window. After the pop-up is closed, I realized that all the key stroke that was supposed to be sent to the pop-up window now sent to text editing area where I brought up the pop-up and it happens occasionally, not always.

No matter if it's a Unity session or Unity2D, I experience the same thing. The only way to avoid it is to remove ibus from language setting.

I was using Unity 4.28.0-ubuntu2 and ibus when I came across this bug.

Hopefully those branch I just attached will be getting merged soon. This will fix the Korean problem, here is a screenshot showing the space and number pad chars committing correctly. Though it is hard to tell, it work ;)

Wow!!! Was it really solved? When can Oneiric users have it?

@Brandon a backport for lp:unity/4.0 please if possible then I'll do the SRU happily

The changes would be to large and would require changes in both unity and nux. 12.04 will be out in a little over 2 months, so you'll have something to look forward too :).

While waiting for the Precise update, Oneiric users could try this:

   - http://cikitsa.blogspot.com/2012/01/ibus-bug-fix.html

Best,
Dominik

On 5 March 2012 09:16, Brandon Schaefer <email address hidden> wrote:

> The changes would be to large and would require changes in both unity

Thanks Dominik, but isn't that the one doesn't work for unity users?

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/880876/comments/10

Maybe that's right, I don't know. I use gnome-shell, where it works fine.

I'll update the blog to say this.

Thanks!

Dominik

This bug was fixed in the package unity - 5.6.0-0ubuntu1

---------------
unity (5.6.0-0ubuntu1) precise; urgency=low

  * New upstream release.
    - compiz crashed with SIGSEGV in g_type_check_instance_cast()
      (LP: #862972)
    - compiz crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()
      (LP: #926793)
    - compiz crashed with SIGSEGV in gdk_pixbuf_get_width() (LP: #937421)
    - Unity causes ibus to not work correctly (spaces incorrectly placed)
      (LP: #880876)
    - Dash - update Dash keyboard shortcuts so the 'CTRL + TAB' switches
      between Lenses and 'TAB' by itself moves the focus between categories
      (LP: #891648)
    - HUD - closing a window with <Alt>+<F4> opens the hud (LP: #923410)
    - unity-applications-daemon crashed with SIGSEGV in
      dee_sequence_model_free_row() (LP: #916356)
    - Launcher, Window Management - Launcher reveal should not be triggered
      when dragging a window (LP: #928805)
    - lenses are loaded on start, should be lazy loaded (LP: #929506)
    - Trash icon jumps about when trying to drag an icon onto it (LP: #932365)
    - HUD loses keypresses for the first second after opening (LP: #932906)
    - HUD doesn't give the focus back to the active application after dash/hud
      use (LP: #934061)
    - Launcher - unpinned apps show with empty pips in the launcher as if they
      exist on another workspace (LP: #937898)
    - Unity Dash should support Keywords parameter in .desktop (formerly X
      -GNOME-Keywords or X-AppInstall-Keywords) (LP: #941231)
    - Support FD.o Desktop Actions spec (LP: #942042)
    - Unity hangs when touching my touchpad/trackpad (LP: #942625)
    - [regression] Pressing alt doesn't show the menu title bar in top panel
      (LP: #943194)
    - Alt + F (or other mnemonic) doesn't work in gnome-terminal (LP: #943239)
    - [unity 5.6] Using Alt+F1 or Alt+F2 sends a ";3P" or ";3Q" to the active
      windows (LP: #943456)
    - [unity 5.6] holding alt and pressing a direction opens the alt-tab list
      in a buggy way (LP: #943902)
    - [unity-5.6] can't enter accents (^o->) in the dash since recent updates
      (LP: #944674)
    - Dash - Keyboard navigation for search filters is broken (LP: #844033)
    - Dash - If mouse highlights one icon in grid, keyboard navigation
      highlights another, so there are 2 highlighted icons (LP: #817436)
    - Alt+Tab default delay of 150ms is too long (LP: #888636)
    - Keyboard shortcut - F10 shortcut is used to show menu and this is wrong
      (LP: #878492)
    - Dash - Currently the app lens doesn't show applications that are
      available for purchase (LP: #916121)
    - Chromium is running, but not showing in launcher or alt-tab.
      (LP: #918474)
    - Dash - Different states of rating stars, and dimensions (LP: #924884)
    - alt-tab confused by a multiple instances of an application on different
      workspaces (LP: #925484)
    - Launcher - Icons are not colorized properly (LP: #930949)
    - Remove glow from Alt-tab edge and Search Field image assets
      (LP: #933578)
    - "Left Mouse Drag" and "Middle Mouse Drag" should be translatable
      (LP: #930510)
    - Launcher switcher...

Brandon and company, thanks for your work. I've updated Precise and it's working now.

Hi Friends, I am a 11.10 user, and I am no techie but a lay person and an ardent campaigner of open source free soft ware, earlier I was using the 11.04 and the IBUS+Itrans(m17n) was fine , but now it is irritating that the Kannada fonts that are very crucial for to write articles as I am a language Journalist. I have the same problem of unnecessary and unwanted space in between the letters while typing Kannada words.
Example: ಅನಿವ ರ್ I have typed Aniver but in Kannada it has come out as Anive r, the space is unwanted.
I need urgent solution.

I'm using the beta version of Ubuntu 12.04 Precise (64bit), and this problem doesn't seem to exist anymore after upgrading a few times from the beta1 (more precisely after upgrading unity). So if you install beta2, it should be fine.

Precise is still in the beta stage, but for me, it's much better than Oneiric. It also has some serious other bugs fixed (e.g https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818830
)

I also had a problem with getting files in NTFS file system on my external HDD when I used Oneiric. It said there was 0 file but there were files. I had had it until I upgraded to the Precise beta.

I mean I had had that NTFS issue until before I upgraded to the Precise beta. So if you are sick of this ibus issue, you'd better try the Precise beta then you may have not only the ibus bug fixed, but also other ones . Yet, it's still beta so it's better to use Live CD or USB to make sure you don't have any major problems with it on you computer.

Similar bug "REGRESSION: can't type characters with accent (dead keys)",
https://bugs.launchpad.net/unity/+bug/961741

There is something wrong with the implementation of the input box for the HUD and Dash.
We cannot type characters with dead keys.
I did not read the code; I suspect that the implementation of the input box does not follow I18n guidelines, which break it for many scripts.

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".