[dash] Search field in Unity can not support iBus

@karl: as discussed today, can you investigate how to connect unity with ibus? thanks

Work has begun on this code and can be found at; lp:~karl-qdh/nux/nux.gtkentry-wrapper

specifically in the examples/gtk_entry_wrapper.cpp/.h files

Currently focus in/out events are being passed correctly and ibus switches input method appropriately, however keystrokes between nux and gdk are incompatible and the mouse position events are currently not in the right place so dragging to select etc is not actually possible..

Todo list is in the gtk_entry_wrapper.cpp file comments at the top

Bunch of things for jaytaoko to work on, mostly polish lookup tables and a bit of co-ordinate jangling/testing.

Marking the oem-priority task in-progress per Comment #2

I'll take this for now. We need to support this for Natty.

With natty alpha-3 and unity-2d 3.6.2-0ubuntu1~bzr449:

I can enable iBus for Chinese/CN pinyin (in unity-2d Search box and in other places) with Ctrl + Space after:
 * installing Chinese from Language Selector (including input methods)
 * setting Chinese as default by dragging it above English and pressing "Apply System Wide"
 * manually* setting the LANG variable in /etc/default/locale, for example: LANG=zh_CN.UTF-8

I believe that manual step should not be necessary and this is the root bug.

This variable is NOT set by Language Support (it was still en_US.UTF-8, my language choice on natty install), even after Chinese installation and selection as default.

I think Ubuntu is transitioning away from LANG to LANGUAGE and other more standard locale variables.

The correction may be to let iBus use the LANGUAGE env var instead of LANG to determine the current locale.

(Indeed all apps that use LANG should transition to LANGUAGE or they too may suffer locale confusion.)

I forgot to mention the need to restart after changing LANG in /etc/default/locale above, so the new var is in effect system wide.

Maybe also (as temporary fix) language selector should just modify that LANG var in /etc/default/locale so that any apps that still read it will pick up the right locale.

Subscribing Gunnar, who did the $LANGUAGE related changes in gdm/language-selector. I believe that language-selector continues to set $LANG as well, it shouldn't have changed in that regard. As with earlier releases, the first tab controls $LANGUAGE (preferred order of language fallbacks for displayed messages, mostly not country specific), and the second tab controls $LANG (general locale settings which are also country specific, such as time/paper/number format).

I reinstalled my box a week ago, and didn't change any of this. My /etc/default/locale says

LANG="de_DE.UTF-8"
LANGUAGE="de:en"
LC_MESSAGES="de_DE.UTF-8"

which looks both correct and backwards compatible to me. I don't believe that the installer changed in that regard either (I think it's ubiquity which writes the original file).

What was the contents of your /e/d/locale after installation? Did you mean that you had to _add_ or to _change_ $LANG there?

I had to _change_ $LANG in /etc/default/locale from en_US.UTF.8 to zh_CN.UTF-8/.

I concur with Martin's point: The Language Selector's second tab does update /etc/default/locale $LANG to the new language.

This is sufficient to enabling iBus, if you follow the right steps.

The result is that unity-2d Search box (and elsewhere) supports iBus through the UI, as follows:

In Language Support:
 * Tab 1: Install Chinese/Simplified translations, input methods, and fonts
 * Tab 1: Apply System-Wide button
 * Tab 1: Select iBus in Keyboard Input Method System combo.
 * Tab2 (named "Regional Formats" in en _US"): Select Chinese and Apply.
 * Reboot/Relogin
 * Ctrl + Space enables /disables iBus

It is arguably a UI design issue that one needs to separately enable input methods after already doing these steps:
 A) Language tab > install/Remove Languages button > Input Methods checkbox
 B) Language tab > Keyboard input method system combo > ibus selection

Enabling input methods also seems somewhat hidden since it occurs on Region Formats tab, whose text discusses Number, Date and Currency formats but that does not mention input methods.

Hello Kyle,

After a number of changes in Ubuntu, LANG is no longer intended for
controlling which language is used for translation of messages in menus
and windows. The changes were made in order to prevent confusion when
users want to apply different locales for message translation
respective other format stuff like dates and numbers.

The language(s) you pick in language-selector's "Language" tab sets the
LANGUAGE and LC_MESSAGES variables, and the underlying assumption is
that applications use either $LANGUAGE or $LC_MESSAGES to determine the
translation language.

Accordingly, if an application uses the $LANG value _directly_ to
determine the translation language, there will be problems if $LANG does
not happen to equal $LC_MESSAGES.

Kyle Nitzsche wrote:
> The correction may be to let iBus use the LANGUAGE env var instead of
> LANG to determine the current locale.

Maybe. The first item in the $LANGUAGE list is not a complete locale
name, though. If it is the locale you are after, you'd better use the
LC_MESSAGES variable.

> (Indeed all apps that use LANG should transition to LANGUAGE or they
> too may suffer locale confusion.)

Hopefully there are not that many of them. To prevent locale confusion,
transition to LC_MESSAGES will do. But it's even better if they are
changed to understand the LANGUAGE priority list, so that non-English
fall back language(s) are recognized.

> The result is that unity-2d Search box (and elsewhere) supports iBus
> through the UI, as follows:
>
> In Language Support:
> * Tab 1: Install Chinese/Simplified translations, input methods, and
> fonts
> * Tab 1: Apply System-Wide button
> * Tab 1: Select iBus in Keyboard Input Method System combo.
> * Tab2 (named "Regional Formats" in en _US"): Select Chinese and
> Apply.
> * Reboot/Relogin
> * Ctrl + Space enables /disables iBus

I saw that you changed the bug status to "Invalid", but to me a need to
set LANG to make iBus work does not seem to be satisfying. If iBus
grabs $LANG directly, I believe it ought to be changed to grab
$LC_MESSAGES instead. Therefore I changed the status to "Confirmed".

> Enabling input methods also seems somewhat hidden since it occurs on
> Region Formats tab, whose text discusses Number, Date and Currency
> formats but that does not mention input methods.

It occurs on the "Language" tab, and there is a tooltip that comments on
input methods. The latter is true as from version 0.25 of
language-selector.

HTH

@ Gunnar. Thanks for your info. This is appreciated!

I think the bug is invalid against unity-2d because getting iBus to work in unity-2d does not require changing unity-2d.

Yes, one can get iBus to work fine if you use Lang Selector in a certain way (described above), but that way is wrong.

As you point out, the open question appears to be: does iBus need to change? That is, does it need to read LANGUAGES or LC_MESSAGES? If so, this should be a bug against the iBus pkg.

On 2011-03-15 00:22, Kyle Nitzsche wrote:
> I think the bug is invalid against unity-2d because getting iBus to
> work in unity-2d does not require changing unity-2d.

Aha, missed that. Changed status back to "Invalid".

> Yes, one can get iBus to work fine if you use Lang Selector in a
> certain way (described above), but that way is wrong.

Ok, then we are agreed.

> As you point out, the open question appears to be: does iBus need to
> change? That is, does it need to read LANGUAGES or LC_MESSAGES? If
> so, this should be a bug against the iBus pkg.

That seems reasonable, so I added ibus to the list above.

/ Gunnar

Since LC_MESSAGES inherits its value from LANG when it's not set explicitly, this ought to be applicable upstream as well. Kyle, please feel free to add details to http://code.google.com/p/ibus/issues/detail?id=1217

> It is arguably a UI design issue that one needs to separately enable input methods after already doing these steps

I agree. The input method should have a sensible default according to the primary selected language.

> Enabling input methods also seems somewhat hidden since it occurs on Region Formats tab

It's not, it's on the first (language) tab. Thus changing the language order (which controls LC_MESSAGES and LANGUAGE) should also control the default input method (which is what the ibus bug is about), but that default should be reflected properly in the combobox.

Hi,

Just a comment.
I think support ibus should not be very hard.
To support Chinese input method, you need to inherit ClutterIMText instead of ClutterText.
ClutterIMText is a subclass of ClutterText, provided in libclutter-imcontext.

So, my suggest is to modify clutk to use ClutterIMText instead of ClutterText. (And add depends on libclutter-imcontext)..

After that, set the environment CLUTTER_IM_MODULE="ibus" and it should support Chinese input.
The media player hornsey is using this to support Chinese inputs.

Regards,
Paul

I don't think the new 11.04 Unity implementations (2D or 3D) use clutter!

Possibly superceded by bug #739812 ("Must use hardware keyboard to perform search for applications in Unity") for which I think DBO has a patch queued up (thought it causes an ABI break).

Why you guys are just changing milestone but take no progress in such a long time?!
Do you know this is a critical issue for input method users? Are you kidding our poor CJK users???!!

......I really don't want to say something like this, you all developers did really good job. I just want this bug to be fixed soon. Thanks.

I had a look at the source of the ibus package and found a patch, written in response to bug #716314, that caught my interest. The comments of that bug report let you know that LC_MESSAGES was considered for determining the locale based default input method. However, due to an upstream choice they ended up with using LC_CTYPE instead.

Considering how Ubuntu deals with locale settings in Natty, I suspect that they should better have sticked to LC_MESSAGES. I replaced LC_CTYPE with LC_MESSAGES in the patch, and uploaded a modified ibus branch to my PPA at https://launchpad.net/~gunnarhj/+archive/misc

It would be great if you could install the ibus package from my PPA, and let us know if the change makes a difference with respect to the issue in this bug report.

I can not understand the logic here. Ubuntu has CJK language support, but CJK users cannot input Cin JK language in unity search box.

And this obvious bug is marked as "wishlist".

@funicorn: I completely agree. this should be critical or high, since without a fix, Unity is significantly broken for users who use input methods.

@funicorn

Because unity 3D uses libnux, a compiz widget library and does not implement XIM support or a iBus IM Module.

Is there any plan to fix it in Ubuntu 11.10?

Until it has been fixed, I won't recommend Ubuntu to my Chinese friends any more. If the CJK users can't search in their languages, how Ubuntu can be an international operating system?

I agree the bug should be critical too.

@Xhacker Liu
@funicorn
@Kyle Nitzsche

Hi guys, any chance that you can help to bring this issue forward by testing the modified ibus package I mentioned in comment #20? Since I do not use input methods, I'm not able to test it properly myself.

@Gunnar Hjalmarsson

Hi Gunnar, I've tested by your PPA, but it doesn't work.

iBus still can't be activated in search box. I think #23 is right, it's not ibus's problem, the problem is libnux.

@Tualatrix
Thanks for testing. Then I put my ibus branch on hold for now.

I'm back to the side issues (but still ibus related) that Kyle Nitzsche described in comment #5 and #10. I figured out that it's not the ibus package that needs to be changed to fix them, but the im-switch package.

For some reason, im-switch currently uses LC_CTYPE to determine the current language. By replacing a couple of occurrences of LC_CTYPE in im-switch with LC_MESSAGES, ibus is started automatically when you would expect it to. I put together an im-switch merge proposal accordingly.

Result: No need to set LANG, and no need to mess with /etc/default/locale at all. If ibus is recommended for the session language, whether it was set in Language Support or on the login screen, the ibus daemon starts during the session startup, and you can conveniently switch ibus on and off with Ctrl + Space.

If you want to check this out before the change is released, you can manually replace LC_CTYPE with LC_MESSAGES at line 24 in /etc/X11/Xsession.d/80im-switch.

Even if this is not the main issue in this bug report, I think it's important enough to those who use input methods to justify a Natty SRU.

@Gunnar: nice!

I would expect that ibus-daemon starts or not depending on the user's locale selection at (g)dm time. That should set the LC_MESSAGES env variable. So, If the user selects a locale that implicates input methods, then $LC_MESSAGES should reflect that, and 'ps aux | grep ibus' should show ibus-daemon is running (and others).

Can people test this? This is really important. We are talking about whether input methods are started properly for a particular user session. If not, people in those parts of the world that *require* input methods to use a computer cannot do so.

Perhaps the larger point is that a single system should support multiple users/accounts, some of which require input methods, and some of which do not, depending on their language (locale). So the ibus-daemon should start at session start up time (or not) depending on the user's *session* language.

Gunnar: have you tested this with light-dm? And, I very much appreciate your following this trail :)

Haven't tested light-dm (yet), so my comments below are based on gdm
only. And to prevent any misunderstandings: The unity 3d issue remains
to be solved.

On 2011-05-20 02:51, Kyle Nitzsche wrote:
> I would expect that ibus-daemon starts or not depending on the
> user's locale selection at (g)dm time.

Yes, that's what happens.

As a side remark, Language Support is the principal tool for selecting
languages and locales. But of course, if you set a language there, that
language is preselected on the login screen next time you log in, and
accepting that setting by doing nothing is also a choice...

> That should set the LC_MESSAGES env variable.

Confirmed. (A tiny detail, though: if LC_MESSAGES happens to equal LANG,
the LC_MESSAGES variable is not set explicitly. But that doesn't matter,
since LC_MESSAGES inherits the LANG value in those cases.)

> So, If the user selects a locale that implicates input methods, then
> $LC_MESSAGES should reflect that, and 'ps aux | grep ibus' should
> show ibus-daemon is running (and others).

Confirmed.

> Can people test this?

Indeed. Since the actual code change is very small, the easiest way is
to edit /etc/X11/Xsession.d/80im-switch as I mentioned in my last
comment. This is what the diff looks like:

--- old/80im-switch 2009-12-06 14:16:40 +0100
+++ /etc/X11/Xsession.d/80im-switch 2011-05-19 08:20:24 +0200
@@ -21,7 +21,7 @@
 _QT_IM_MODULE=$QT_IM_MODULE

 # $LNG is locale <language>_<region> without .<encoding> and .<encoding>@EURO
-LNG=${LC_ALL:-${LC_CTYPE:-${LANG}}}
+LNG=${LC_ALL:-${LC_MESSAGES:-${LANG}}}
 LNG=${LNG%@*}
 LNG=${LNG%.*}

> Perhaps the larger point is that a single system should support
> multiple users/accounts, some of which require input methods, and
> some of which do not, depending on their language (locale). So the
> ibus-daemon should start at session start up time (or not) depending
> on the user's *session* language.

Even if I haven't tested that either, I can't see a reason why it
shouldn't work just like that.

This bug was fixed in the package im-switch - 1.20ubuntu4

---------------
im-switch (1.20ubuntu4) oneiric; urgency=low

  * 80im-switch and im-switch.in:
    - Replace occurrences of LC_CTYPE with LC_MESSAGES, since the
      latter unlike LC_CTYPE represents the current language in Ubuntu.
      That way e.g. the ibus daemon will start automatically at session
      startup if the current language is mapped to ibus (LP: #663776).
 -- Gunnar Hjalmarsson <email address hidden> Fri, 20 May 2011 01:50:00 +0200

Accepted im-switch into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

@Kyle and others
If you test the changes, and since a package with the modifications is now available in natty-proposed, please follow Martin's request to install that package and post the result here, and disregard my tip about manually editing a file. That way it will make it to natty-updates faster.

Dash doesn't support input method is caused by the limitation of nux, why
this bug is relevant to im-switch and language-support?
Because nux doesn't support XIM or native IMMODULE, so we can't use any
input methed together with nux

On Sat, May 21, 2011 at 9:04 PM, Gunnar Hjalmarsson <
<email address hidden>> wrote:

> @Kyle and others
> If you test the changes, and since a package with the modifications is now
> available in natty-proposed, please follow Martin's request to install that
> package and post the result here, and disregard my tip about manually
> editing a file. That way it will make it to natty-updates faster.
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (729523).
> https://bugs.launchpad.net/bugs/663776
>
> Title:
> [dash] Search field in Unity can not support iBus
>
> Status in IBus:
> Unknown
> Status in OEM Priority Project:
> In Progress
> Status in Ubuntu Translations:
> New
> Status in Unity:
> In Progress
> Status in Unity 2D:
> Invalid
> Status in “im-switch” package in Ubuntu:
> Fix Released
> Status in “language-selector” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> In Progress
> Status in “im-switch” source package in Natty:
> Fix Committed
> Status in “language-selector” source package in Natty:
> Won't Fix
> Status in “unity” source package in Natty:
> In Progress
>
> Bug description:
> Binary package hint: unity
>
> as title
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>

lp:~gunnarhj/ubuntu/oneiric/im-switch/lp-663776 looks strange, ibus can be
started with any UTF-8 locale, its obviously nothing wrong with im-switch.

On Mon, May 23, 2011 at 7:32 AM, Zhengpeng Hou <email address hidden>wrote:

> Dash doesn't support input method is caused by the limitation of nux, why
> this bug is relevant to im-switch and language-support?
> Because nux doesn't support XIM or native IMMODULE, so we can't use any
> input methed together with nux
>
>
> On Sat, May 21, 2011 at 9:04 PM, Gunnar Hjalmarsson <
> <email address hidden>> wrote:
>
>> @Kyle and others
>> If you test the changes, and since a package with the modifications is now
>> available in natty-proposed, please follow Martin's request to install that
>> package and post the result here, and disregard my tip about manually
>> editing a file. That way it will make it to natty-updates faster.
>>
>> --
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug (729523).
>> https://bugs.launchpad.net/bugs/663776
>>
>> Title:
>> [dash] Search field in Unity can not support iBus
>>
>> Status in IBus:
>> Unknown
>> Status in OEM Priority Project:
>> In Progress
>> Status in Ubuntu Translations:
>> New
>> Status in Unity:
>> In Progress
>> Status in Unity 2D:
>> Invalid
>> Status in “im-switch” package in Ubuntu:
>> Fix Released
>> Status in “language-selector” package in Ubuntu:
>> Triaged
>> Status in “unity” package in Ubuntu:
>> In Progress
>> Status in “im-switch” source package in Natty:
>> Fix Committed
>> Status in “language-selector” source package in Natty:
>> Won't Fix
>> Status in “unity” source package in Natty:
>> In Progress
>>
>> Bug description:
>> Binary package hint: unity
>>
>> as title
>>
>> To unsubscribe from this bug, go to:
>> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>>
>
>

@ZhengPeng Hou that's is another bug, Gunnar Hjalmarsson are working a bug effect unity-2d

I'm still wondering anything wrong with im-switch

On Mon, May 23, 2011 at 9:37 AM, Hsin-Yi, Chen (hychen) <
<email address hidden>> wrote:

> @ZhengPeng Hou that's is another bug, Gunnar Hjalmarsson are working a
> bug effect unity-2d
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (729523).
> https://bugs.launchpad.net/bugs/663776
>
> Title:
> [dash] Search field in Unity can not support iBus
>
> Status in IBus:
> Unknown
> Status in OEM Priority Project:
> In Progress
> Status in Ubuntu Translations:
> New
> Status in Unity:
> In Progress
> Status in Unity 2D:
> Invalid
> Status in “im-switch” package in Ubuntu:
> Fix Released
> Status in “language-selector” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> In Progress
> Status in “im-switch” source package in Natty:
> Fix Committed
> Status in “language-selector” source package in Natty:
> Won't Fix
> Status in “unity” source package in Natty:
> In Progress
>
> Bug description:
> Binary package hint: unity
>
> as title
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>

Hi ZhengPeng,

On 2011-05-23 01:41, ZhengPeng Hou wrote:
> lp:~gunnarhj/ubuntu/oneiric/im-switch/lp-663776 looks strange, ibus
> can be started with any UTF-8 locale, its obviously nothing wrong
> with im-switch.

In comments #5 and #10 Kyle brought our attention to that ibus does not
easily start automagically based on the selected language. That's the
issue the branch you mention aims to address.

You may still be right when saying that there is nothing wrong with
im-switch. When Colin Watson sponsored my proposal, we agreed to
consider the change to be a temporary workaround. Please see bug 786986.

Hi Zhengpeng,

I found that ibus-daemon only starts at (g)dm session start time when $LANG implicates a language that uses input methods. Since LANG is used for formats (date, numbers, etc), this seems wrong.

Also, I found that ibus-daemon would not start at (g)dm session time if LANG did not implicate input methods (for example, if LANG=en_US.UTF-8) even if the user selects Chinese/Simplified (for example) at (g)dm login.

I *think* the ibus-daemon should start (or not start) depending on the session level variable that shows the translation, not the format. I believe this is what Gunnar's work addresses.

@gunnar, Regarding your proposed fix for input methods not starting based on *session* user language:

Using im-switch 1.20ubunu3.1 from proposed, the issue described in #39 appears resolved. That is, LANG does not control whether ibus-daemaon starts on session start but instead session user-selected language does.

There are four main cases, involving various combinations of languages that do and do not imply input methods, I think. I used English/US (en_US.UTF-8) and Chinese/Simplified (zh_CN.UTF-8) to test.

1) LANG=en_US.UTF-8; user selects English (US) at gdm.
Expected result: ibus does not start at session start up time
Actual result: ibus does NOT start
VERIFIED

2) LANG=en_US.UTF-8; user selects Chinese/Simplified at gdm.
Expected result: ibus does start at session start up time
Actual result: ibus DOES start
VERIFIED

3) LANG=zh_CN.UTF-8; user selects English (US) at gdm.
Expected result: ibus does not start at session start up time
Actual result: ibus does NOT start
VERIFIED

4) LANG=zh_CN.UTF-8; user selects Chinese/Simplified at gdm.
Expected result: ibus does start at session start up time
Actual result: ibus DOES start
VERIFIED

Based on this, my opinion is the fix works. I hope native Chinese/Simplified can do additional testing to ensure ibus there are no regressions.

Note that this is probably NOT, as you noted, the main issue: that input methods do not work in Unity search bar.

Thanks for testing it, Kyle! My testing of im-switch 1.20ubunu3.1 gave the same result, so then there are two of us that has verified that the package installs and runs as expected, and that it does fix the issues it's supposed to.

if you want to use ibus under any UTF-8 locale, you need set it by
im-switch -s ibus
and this can be called within language-selectot, we don't need do any
workaround in im-switch. And there do have a option in language-selector to
enable input method, not only support ibus, but also other input method.
And ibus is not designed to start automatically based on selected locale

On Tue, May 24, 2011 at 5:27 AM, Gunnar Hjalmarsson <
<email address hidden>> wrote:

> Thanks for testing it, Kyle! My testing of im-switch 1.20ubunu3.1 gave
> the same result, so then there are two of us that has verified that the
> package installs and runs as expected, and that it does fix the issues
> it's supposed to.
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (729523).
> https://bugs.launchpad.net/bugs/663776
>
> Title:
> [dash] Search field in Unity can not support iBus
>
> Status in IBus:
> Unknown
> Status in OEM Priority Project:
> In Progress
> Status in Ubuntu Translations:
> New
> Status in Unity:
> In Progress
> Status in Unity 2D:
> Invalid
> Status in “im-switch” package in Ubuntu:
> Fix Released
> Status in “language-selector” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> In Progress
> Status in “im-switch” source package in Natty:
> Fix Committed
> Status in “language-selector” source package in Natty:
> Won't Fix
> Status in “unity” source package in Natty:
> In Progress
>
> Bug description:
> Binary package hint: unity
>
> as title
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>

@Kyle,
Your testing case is obviously wrong. if you want to use ibus/or any input
method, you need enable it firstly in your own session. If you run input
method automatically under any locale, people will be confused, for many
non-cjk users don't need it, just like you, and we had similar approach to
let input method start automatically for everyone in 6.06, users complained.

On Mon, May 23, 2011 at 11:38 PM, Kyle Nitzsche <<email address hidden>
> wrote:

> @gunnar, Regarding your proposed fix for input methods not starting
> based on *session* user language:
>
> Using im-switch 1.20ubunu3.1 from proposed, the issue described in #39
> appears resolved. That is, LANG does not control whether ibus-daemaon
> starts on session start but instead session user-selected language does.
>
> There are four main cases, involving various combinations of languages
> that do and do not imply input methods, I think. I used English/US
> (en_US.UTF-8) and Chinese/Simplified (zh_CN.UTF-8) to test.
>
> 1) LANG=en_US.UTF-8; user selects English (US) at gdm.
> Expected result: ibus does not start at session start up time
> Actual result: ibus does NOT start
> VERIFIED
>
> 2) LANG=en_US.UTF-8; user selects Chinese/Simplified at gdm.
> Expected result: ibus does start at session start up time
> Actual result: ibus DOES start
> VERIFIED
>
> 3) LANG=zh_CN.UTF-8; user selects English (US) at gdm.
> Expected result: ibus does not start at session start up time
> Actual result: ibus does NOT start
> VERIFIED
>
> 4) LANG=zh_CN.UTF-8; user selects Chinese/Simplified at gdm.
> Expected result: ibus does start at session start up time
> Actual result: ibus DOES start
> VERIFIED
>
> Based on this, my opinion is the fix works. I hope native
> Chinese/Simplified can do additional testing to ensure ibus there are no
> regressions.
>
> Note that this is probably NOT, as you noted, the main issue: that input
> methods do not work in Unity search bar.
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (729523).
> https://bugs.launchpad.net/bugs/663776
>
> Title:
> [dash] Search field in Unity can not support iBus
>
> Status in IBus:
> Unknown
> Status in OEM Priority Project:
> In Progress
> Status in Ubuntu Translations:
> New
> Status in Unity:
> In Progress
> Status in Unity 2D:
> Invalid
> Status in “im-switch” package in Ubuntu:
> Fix Released
> Status in “language-selector” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> In Progress
> Status in “im-switch” source package in Natty:
> Fix Committed
> Status in “language-selector” source package in Natty:
> Won't Fix
> Status in “unity” source package in Natty:
> In Progress
>
> Bug description:
> Binary package hint: unity
>
> as title
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>

@Zhengpeng,

Who said input methods should start automatically under any locale?

If you read again, you will see that the goal is that input methods start only if the user-selected language in gdm requires them.

@ZhengPeng
The file /etc/X11/Xsession.d/80im-switch, which automatically enables applicable input method based on locale, has been there since Lucid. The feature was affected by the i18n changes in Natty. Now we try to make it work as it was designed to do.

You seem to prefer that the feature is disabled. How would, in you opinion, doing so benefit the input method users?

On Tue, May 24, 2011 at 7:22 AM, Kyle Nitzsche
<email address hidden>wrote:

> @Zhengpeng,
>
> Who said input methods should start automatically under any locale?
>
> If you read again, you will see that the goal is that input methods
> start only if the user-selected language in gdm requires them.

This should not be the case either. Unless you want implement another
option for users to enable/disable input method from gdm.

>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (729523).
> https://bugs.launchpad.net/bugs/663776
>
> Title:
> [dash] Search field in Unity can not support iBus
>
> Status in IBus:
> Unknown
> Status in OEM Priority Project:
> In Progress
> Status in Ubuntu Translations:
> New
> Status in Unity:
> In Progress
> Status in Unity 2D:
> Invalid
> Status in “im-switch” package in Ubuntu:
> Fix Released
> Status in “language-selector” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> In Progress
> Status in “im-switch” source package in Natty:
> Fix Committed
> Status in “language-selector” source package in Natty:
> Won't Fix
> Status in “unity” source package in Natty:
> In Progress
>
> Bug description:
> Binary package hint: unity
>
> as title
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>

Zh

@Zhengpeng,

Please say what you think is the correct *functionality* (from a high level) for input method daemon startup at user login time for the user selected language at (g)dm time.

I think Ubuntu should support multiple users. Some might want the input method daemon running, some might not. Currently, I think the daemon *only* starts if the LANG variable implies a locale for imput methods, even if the user selects Chinese/Simplified at (g)dm time. This does not seem right to me. I think the daemon should start up at gdm session start time only if the user selects (in gdm) a language for which input methods are appropriate. (I did my testing - above - by manually editing /etc/default/locale: LANG, not by using Language Suppor application. It is possible that this testing is invalid.

The fix Gunnar pushed (and I thought was right) was that the input method daemon should start if the user selects at gdm time a language that requires input methods.

@Kyle
From CJK users perspective, we will enable input method within user session,
and re-login to get it work, like you choose Chinese through
language-selector, and enable input method, re-login, you will get IM
running automatically. Or language-support-input-xx has been installed, user
choose the same locale, IM will run automatically.

On Tue, May 24, 2011 at 10:22 AM, Kyle Nitzsche <<email address hidden>
> wrote:

> @Zhengpeng,
>
> Please say what you think is the correct *functionality* (from a high
> level) for input method daemon startup at user login time for the user
> selected language at (g)dm time.
>
> I think Ubuntu should support multiple users. Some might want the input
> method daemon running, some might not. Currently, I think the daemon
> *only* starts if the LANG variable implies a locale for imput methods,
> even if the user selects Chinese/Simplified at (g)dm time. This does not
> seem right to me. I think the daemon should start up at gdm session
> start time only if the user selects (in gdm) a language for which input
> methods are appropriate. (I did my testing - above - by manually editing
> /etc/default/locale: LANG, not by using Language Suppor application. It
> is possible that this testing is invalid.
>
> The fix Gunnar pushed (and I thought was right) was that the input
> method daemon should start if the user selects at gdm time a language
> that requires input methods.
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (729523).
> https://bugs.launchpad.net/bugs/663776
>
> Title:
> [dash] Search field in Unity can not support iBus
>
> Status in IBus:
> Unknown
> Status in OEM Priority Project:
> In Progress
> Status in Ubuntu Translations:
> New
> Status in Unity:
> In Progress
> Status in Unity 2D:
> Invalid
> Status in “im-switch” package in Ubuntu:
> Fix Released
> Status in “language-selector” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> In Progress
> Status in “im-switch” source package in Natty:
> Fix Committed
> Status in “language-selector” source package in Natty:
> Won't Fix
> Status in “unity” source package in Natty:
> In Progress
>
> Bug description:
> Binary package hint: unity
>
> as title
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>

@Gunnar, @Kyle
Thanks for your efforts and analysis! However, for me I don't think
locale is a strong enough cue to determine whether to start input
methods or not. User preferences should be the first priority. At
least, a user may choose English as their desktop language for
numerous reasons, but he/she may still want to input characters in
other languages.

The locale or desktop language can provide a good guess on installing
the system or creating an account. But later I think we should only
refer to the user preferences. Besides, one will feel weird if the
input method goes away after it changes the language of display. I
strongly disagree with this.

Besides, I'm not sure about Ubuntu's bug policy, but I'm afraid the
problem you are talking about is not quite closely related to the bug
topic "Search field in Unity can not support iBus". Probably starting
another bug about this is better. To me and possibly most of the
subscribers to this bug, the original bug is "critical", not this one.

CHEN, Xing / 陈醒

2011/5/23 Gunnar Hjalmarsson <email address hidden>:
> @ZhengPeng
> The file /etc/X11/Xsession.d/80im-switch, which automatically enables applicable input method based on locale, has been there since Lucid. The feature was affected by the i18n changes in Natty. Now we try to make it work as it was designed to do.
>
> You seem to prefer that the feature is disabled. How would, in you
> opinion, doing so benefit the input method users?
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/663776
>
> Title:
>  [dash] Search field in Unity can not support iBus
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>

@Chen:
Yes, this topic should have been discussed in a separate bug all along.

@Zhengpeng:
Thanks for your comments.

@Gunnar:
Let's take this off line. It may turn out that the proposed im-switch change is not needed. I will do some further tests informed by the above and let you know how things look and bring Zhengpeng in as well.

@Gunnar, Zhengpeng and Chen:

To close out the discussion of this *side* topic, I now think input method starting/not starting on user session works as designed.

The behavior is that if the user has input methods installed, and if they enable input methods in gnome-language-selector, ibus will run in their session, regardless of the user's language selection at gdm time, and even if the top-most language in language selector does not imply input methods (for example English), and they can use Ctrl + Space to enable/disable IM. If there are multiple users on the system, each can independently control whether ibus starts up using this mechanism.

See attachment with details of steps I took to verify this.

@Gunnar, thanks (a LOT) for your work, but based on the info provided above and my latest testing, I think the proposed change to im-switch is not needed.

My error was doing testing by modifying /etc/default/locale: LANG variable directly instead of using the Language Selector GUI.

Well, in the light of how Ubuntu handles languages and locales in Natty, I still think there is a need to modify the way the input method system selection works. Ubuntu now consequently distinguishes between languages and region specific formats. However, the input method system preference is set in language-selector for the current regional formats setting, which makes little sense. Setting it for the current language is a better assumption on the actual relation.

Kyle, what you actually did when you enabled ibus was telling the system that ibus shall be started when en_US is selected on the second tab. If you would change the regional formats setting to e.g. de_DE and reboot, IM would not be started. That's not a behavior we will keep, is it?

There have been quite a few misconceptions in this discussion, and I wouldn't like to drop a desired change based on the discussion so far. Instead, in the hope that it will clarify things, I made a few modifications to language-selector in response to Martin Pitt's suggestion in comment #15. A Natty package with those mods is available in my PPA: https://launchpad.net/~gunnarhj/+archive/misc

With that package and the modified im-switch package follow two principal changes:
- Input method system mapped to language, not regional formats
- Changing the language in language-selector is instantly reflected on
  the input method system control, meaning that you can change it if
  you don't like the default.

It would be great if those who are interested in this aspect of input methods could install both the packages and check out the behavior. Then, hopefully, the remaining discussion could be hold based on actual tests of the proposed code.

@Gunnar,

Can you please make a new bug for this, since it is orthogonal to input methods not working in Unity Home Dash Search?

Also, I think this whole *side* conversation highlights a *critical* need for clearly articulated expectations for Ubuntu input methods on a multiuser system with multiple languages. Someone should own the job of developing and articulating those expectations.

I found a strange issue in dash search. Since I cannot use Chinese to
search for applications in dash, I tried to type just "synaptic", but it
does NOT find synaptic package manager, I may need to search for the
application name in Chinese, which is not doable due to this bug.

However, I found that some other applications DOES work when searching for
their executable name, for example I can search for gnome-activity-journal
directly in dash, although its display name is in Chinese.

I am aware that I can use alt-f2 to do a fine name search, but isn't it
better to unify all kind of searches into one place? Could anyone explain
this behavior, or if I am unaware of any settings/tricks?

2011/5/25 Kyle Nitzsche <email address hidden>

> @Gunnar,
>
> Can you please make a new bug for this, since it is orthogonal to input
> methods not working in Unity Home Dash Search?
>
> Also, I think this whole *side* conversation highlights a *critical*
> need for clearly articulated expectations for Ubuntu input methods on a
> multiuser system with multiple languages. Someone should own the job of
> developing and articulating those expectations.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/663776
>
> Title:
> [dash] Search field in Unity can not support iBus
>
> Status in IBus:
> Unknown
> Status in OEM Priority Project:
> In Progress
> Status in Ubuntu Translations:
> New
> Status in Unity:
> In Progress
> Status in Unity 2D:
> Invalid
> Status in “im-switch” package in Ubuntu:
> Fix Released
> Status in “language-selector” package in Ubuntu:
> In Progress
> Status in “unity” package in Ubuntu:
> In Progress
> Status in “im-switch” source package in Natty:
> Fix Committed
> Status in “language-selector” source package in Natty:
> Won't Fix
> Status in “unity” source package in Natty:
> In Progress
>
> Bug description:
> Binary package hint: unity
>
> as title
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>

On Wed, May 25, 2011 at 09:00, Shannon <email address hidden> wrote:
> I found a strange issue in dash search.  Since I cannot use Chinese to
> search for applications in dash, I tried to type just "synaptic", but it
> does NOT find synaptic package manager, I may need to search for the
> application name in Chinese, which is not doable due to this bug.
>
> However, I found that some other applications DOES work when searching for
> their executable name, for example I can search for gnome-activity-journal
> directly in dash, although its display name is in Chinese.
>
> I am aware that I can use alt-f2 to do a fine name search, but isn't it
> better to unify all kind of searches into one place?  Could anyone explain
> this behavior, or if I am unaware of any settings/tricks?
>

The reason might be the translator simply translated the search
keywords, but not append the relevant strings to the English ones. I
didn't do much in Natty cycle so I don't know the exact situation, but
this is the only reason I can think of. I'll be back in no more than a
month to work on Oneiric hopefully, and might be able to handle this
problem before its release.

--
Regards,
Aron Xu

Thanks Aron.

If you had any chance to examine this piece of code. I would strongly
suggest to alter dash search algorithm to always fallback to the executable
file name, rather than relying on translators to append original strings
etc.

2011/5/25 Aron Xu <email address hidden>

> On Wed, May 25, 2011 at 09:00, Shannon <email address hidden> wrote:
> > I found a strange issue in dash search. Since I cannot use Chinese to
> > search for applications in dash, I tried to type just "synaptic", but it
> > does NOT find synaptic package manager, I may need to search for the
> > application name in Chinese, which is not doable due to this bug.
> >
> > However, I found that some other applications DOES work when searching
> for
> > their executable name, for example I can search for
> gnome-activity-journal
> > directly in dash, although its display name is in Chinese.
> >
> > I am aware that I can use alt-f2 to do a fine name search, but isn't it
> > better to unify all kind of searches into one place? Could anyone
> explain
> > this behavior, or if I am unaware of any settings/tricks?
> >
>
> The reason might be the translator simply translated the search
> keywords, but not append the relevant strings to the English ones. I
> didn't do much in Natty cycle so I don't know the exact situation, but
> this is the only reason I can think of. I'll be back in no more than a
> month to work on Oneiric hopefully, and might be able to handle this
> problem before its release.
>
>
> --
> Regards,
> Aron Xu
>

This bug was fixed in the package language-selector - 0.37

---------------
language-selector (0.37) oneiric; urgency=low

  * LanguageSelector/gtk/GtkLanguageSelector.py (LP: #663776):
    - When setting an input method system, map it to the current
      language, not the current regional formats setting.
    - When changing the top-most language in the combobox on the first
      tab, update instantly the active value on the input method system
      drop down list to reflect the language switch.
 -- Gunnar Hjalmarsson <email address hidden> Wed, 25 May 2011 09:48:47 +0200

After the upgrade of the im-switch, I have to start ibus manually in the English locale, the ibus-daemon won't start automatically. What a pity.

@Tualatrix
If you also install the updated language-selector package (Natty version in my PPA: https://launchpad.net/~gunnarhj/+archive/misc) you can easily change that.

* If you drag e.g. zh_TW to the top on the first tab in language-selector, the input method system control shows "ibus", since that's the default for zh_TW.

* If you drag English to the top, the control is blank, since the default for English is to not start any input method system. By switching to "ibus" you tell the system: "When the selected language is English, start ibus automatically at login."

Not that pity after all, right? :)

@All
I missed at first that the im-switch change was an insufficient fix, and that language-selector should be changed as well. Sorry for the confusion it may have caused.

As Kyle suggested, I opened the bug #788033 as a place to further talk about IM management, in order to avoid further noise on this bug report about a side topic.

@Gunnar
Honestly, existing IM management is fine enough, its very simple, please
don't make it more complicated. I know you're trying to help, and also we
appreciate your effort.
Besides, im-switch might be replaced by im-config in Ubuntu soon, because
upstream author has been focus on im-config already.

On Wed, May 25, 2011 at 6:31 PM, Gunnar Hjalmarsson <
<email address hidden>> wrote:

> @Tualatrix
> If you also install the updated language-selector package (Natty version in
> my PPA: https://launchpad.net/~gunnarhj/+archive/misc) you can easily
> change that.
>
> * If you drag e.g. zh_TW to the top on the first tab in language-
> selector, the input method system control shows "ibus", since that's the
> default for zh_TW.
>
> * If you drag English to the top, the control is blank, since the
> default for English is to not start any input method system. By
> switching to "ibus" you tell the system: "When the selected language is
> English, start ibus automatically at login."
>
> Not that pity after all, right? :)
>
> @All
> I missed at first that the im-switch change was an insufficient fix, and
> that language-selector should be changed as well. Sorry for the confusion it
> may have caused.
>
> As Kyle suggested, I opened the bug #788033 as a place to further talk
> about IM management, in order to avoid further noise on this bug report
> about a side topic.
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (729523).
> https://bugs.launchpad.net/bugs/663776
>
> Title:
> [dash] Search field in Unity can not support iBus
>
> Status in IBus:
> Unknown
> Status in OEM Priority Project:
> In Progress
> Status in Ubuntu Translations:
> New
> Status in Unity:
> In Progress
> Status in Unity 2D:
> Invalid
> Status in “im-switch” package in Ubuntu:
> Fix Released
> Status in “language-selector” package in Ubuntu:
> Fix Released
> Status in “unity” package in Ubuntu:
> In Progress
> Status in “im-switch” source package in Natty:
> Fix Committed
> Status in “language-selector” source package in Natty:
> Won't Fix
> Status in “unity” source package in Natty:
> In Progress
>
> Bug description:
> Binary package hint: unity
>
> as title
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ibus/+bug/663776/+subscribe
>

@ZhengPeng
Please see this as a fix of a regression bug due to the i18n changes in Natty. Since you can keep using im-switch in the same manner as before, and are fine with it, I understand if you think the fix is unnecessary. But for the same reason I don't understand how it would be more complicated.

Now it works as intended, and the behavior can (and will) be documented in Language Support Help.

If it's decided to replace im-switch with im-config, let's see to it that im-config is correctly implemented in Ubuntu to start with.

Gunnar and I discussed that again. We both agree that the im-switch and language-selector changes should go into natty-updates together or not at all. However, the im-switch SRU changes current behaviour unexpectedly without user interaction, so while the fix is correct, I think the impact in an SRU is too high. Therefore I withdrawed the im-switch package in natty-proposed.

well , I personally appreciate #52's way of thinking. Linking IM to either LANG or LC is no good compared to making it a decision up to practical needs. Any preset "matching" pattern is, essentially speaking, choice on behalf of others. Since either pattern is not satisfying enough, it's better to let go.

@funicorn
It's not either or, it's both.

im-switch provides default links between language and input method system. Via the IM control in Language Support you can change the input method system for respective language.

im-switch and its successor, im-switch are the only way of managing input method blessed by the Debian pkg-ime team. This means ibus and other input methods maintained by the team will not be supported if any glitch happens in other way of manipulating the settings. Thus I'm against the changes in im-switch and language-selector about im settings, it does make our life harder when dealing with different programs doing similar things but with different implementations.

This is a critical issue for input method users. It affect most of users in Asia include China, Japan, Korea & Taiwan. Due to this issue, we are not able to adapt 11.04 with Unity for customer who want to ship their product with Ubuntu in Asia, especially in China.
Please make sure this issue is addressed in 11.10, or we will face big challenge from our customers and users at that time.

This is critical functionality for users in Asia; related to bug 745243

I've tested on the latest Ubuntu 11.10 with iBus input method (Chinese locale), everything works fine!

I can say Unity is ready for CJK users now!

Thanks for the hard work, all Unity developers, thank you!

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

---------------
unity (4.12.0-0ubuntu1) oneiric; urgency=low

  * New upstream release.
    - P3: [natty] Cannot click on indicators (LP: #819202)
    - Icons not visible in the launcher or alt-tab switcher (LP: #833905)
    - [dash] Search field in Unity can not support iBus (LP: #663776)
    - [dash] preferred applications are not stored in GConf anylonger
      (LP: #805063)
    - SysTray icons have a white square background in Unity. (LP: #823407)
    - new dash does not fit a normal netbook screen (LP: #825370)
    - Dash picks random weird colors (yellow, green), fonts invisible (with
      blur en- or disabled) (LP: #828363)
    - Music Lens doesn't display items until you search (LP: #824892)
    - Dash - Adjustments to stateful behaviour (LP: #838667)
    - Dragging from dash to launcher still doesn't work (LP: #824833)
    - Click on 'More Apps' et al closes the dash (LP: #824842)
    - cannot paste into dash (particularly relevant for alt+f2) (LP: #736222)
    - Ctrl X doesn't cut selected text in Dash search field (LP: #737731)
    - Ctrl+C doesn't copy selected text in Dash search field (LP: #737732)
    - The indicators shows a big white square when systray whitelisted
      (LP: #822672)
    - ARM FTBFS fix (LP: #834576)
  * debian/control:
    - build on latest nux
  * debian/rules:
    - bump shlibs
 -- Didier Roche <email address hidden> Thu, 01 Sep 2011 17:33:06 +0200

It is not fixed completely.
The search field can't show converted words until pressing "Enter".

At testing latest version of Unity, I was happy.
But soon, I agreed with @Koichi.
I'm Korean user, but I know a little bit about typing Japanese and Chinese.
Unity can't show and process typing letter(1 CJK letters are typed by several key pressing).
It looks like Unity has problem to CJK all!

*Korean
Korean letters are type like as lego blocks.
ex 1) '가'='ㄱ'+'ㅏ'
ex 2) '간'='ㄱ'+'ㅏ'+'ㄴ'
As you see, type 'ㄴ' makes '가' to '간'.
And it means the letter '가' can be typed done, or not.
So, ibus makes typing letter blocked to show "it can be typed or not".
But Unity didn't show typing letter and it maked Korean users to not know what they are typing!
ex)When type '가나다라', latest letter '라' is on typing, so Unity only show '가나다' and just searching '가나다', not '가나다라'

*Chinese
@Ding said he tested with ibus.
I tested with ibus-pinyin, and it seems pressing arrow keys(Chinese letters are listed, and selected by number or arrow) sometines go to Unity, sometimes go to ibus.
ex) 你 : type ni > show list pronounced ni (你泥尼妮拟...) > select with number key(in this time, 1) or arrow & space
I'm, not Chinese so I'm wondering it's a problem or not.

*Japanese
Pressing Enter makes typing letters marked finished.
ex) ありがとう : type "arigatou"> Press Enter >Finished
But before press Enter, Unity didn't get any letters and thus search nothing.
For now, the only way is they press Enter key every time at one letters.
ex)　ありがとう : a > enter > ri > enter > ga > enter > to > enter > u > enter

Anyway, thank you for improve Unity better!

p.s If you are Chinese or Japanese and find out something wrong in this comment, don't hesitate to say it!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/04/2011 03:57 PM, jincreator wrote:
> At testing latest version of Unity, I was happy.
> But soon, I agreed with @Koichi.
> I'm Korean user, but I know a little bit about typing Japanese and Chinese.
> Unity can't show and process typing letter(1 CJK letters are typed by several key pressing).
> It looks like Unity has problem to CJK all!

I tested it with the latest version on Oneiric and it works like
expected. The pre-edit stuff appears in the search field, so you can see
what you type.

I tested with ibus-hangul (Korean), ibus-anthy (Japanese) and
ibus-pinyin (Chinese).

The difference you described is the following: in hangul, you compose
the syllables out of letters, like you described. There is no ambiguity,
each syllable is unique. Therefor ibus submits the syllable when it's
complete. Means, either you press Space or Enter to signal that the
syllable is complete, or you start typing a new syllable, where ibus
knows that the last component you typed can't be part of the syllable
you typed before and therefore must be part of a new syllable.
In Japanese and Chinese however, things work differently. Since we type
the pronunciation and each pronunciation can map to multiple characters
(words), we need to choose which characters we want. The input engines
nowadays are smart enough to select the correct characters for whole
sentences, by context search. Therefore we type the complete sentence in
the pre-edit phase and review if the engine has chosen the correct
characters. We can go back with the arrow keys and correct any wrongly
chosen characters.
Only when we are satisfied we submit the whole string with either Enter
or Space, depending on the input method.

Hence, the scenario you described is expected. Nothing wrong with it. :)

Cheers
Arne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJOZFMdAAoJENiwmJtstTzsDdEP/isDlCa/ys8L85SyZDu87HyP
VgGDsICFCKG0ZNEqY+zqhfafbHUe7m56QFMPdslBkw4m9AZOOfYqG/XHWiTdwuD4
AGUeh5kuXDYfYOCaq6E7tEWu+nBYLLh8xMAe4/Qs8xUIGRhpx6iRgyyN6YmxAseZ
wNlG7fPPn1PrzLX/VevdRnIRT7tO0khZnmQ2QPTQ0OocPFKK8iNKz2IxOVvjXo6F
iaEAHdzL2QWTuyfVd9p5oHko3fyZKk/Ra0pVesBdXaXhrjWFuEh/2ws2iYJep8SA
sIBjOSYRWtPyLO5EE1cC6w5WaX0O34GE+vEC3f7GWvKhODE9+FSYwFI/ycDedPXU
0x8/h7Z14vUuPZesTqeHGkvr+PZGQZWQyctYn55A/LdIiCkPL9glZoQ97mWH/r0n
UweXW8MuodKjh5TibpFFgGHdWRggkwe0jsA68BSKGiAKxfgvAKN+1zVeWp6wc91f
w9zPaTIFwlmyX01IflXAFGiUCqj3IJLKuRQzhSEGOXpF+AHVWJ13IkgACDyM+8e5
Xx1yMNRsRYpo1ZGTyhQbW+3Jk0hO+iw6pDRonKTzMemQbQcHpQZMzD/C1x524GLa
ZExelmlT16IGe3wx00kfcjMjF7PiiVqVbeNM6ubxIYx4IGVp9zPk9DiYWzg4WsHZ
CJnU8LxtieaxeK+J9mrU
=pndd
-----END PGP SIGNATURE-----

"Only when we are satisfied we submit the whole string with either Enter
or Space, depending on the input method"
@Arne, that's the problem I think.
Unity must show and search the letter(string) even it's not complete.

Did you tried Google using Instant Search(default setting)?
Google Instant Search show and search with whole incomplete string even you didn't enter, space, type next character and so on.
As you see attached image from Koichi, there's 4 letters but not completed.
Google start to search it using 4 letters, but Unity didn't try to search it.

Yes, I know CJK users "can" search with CJK letters and input method.
But it's really annoying to press lots of keys for find 2 letters or press enter several times.
Also, it's too unfamiliar to people who use Unity first.
Because Windows and Mac doesn't have this problem it can even make Ubuntu's first impression bad!

Please consider this bug one more time.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/06/2011 12:26 AM, jincreator wrote:
> "Only when we are satisfied we submit the whole string with either Enter
> or Space, depending on the input method"
> @Arne, that's the problem I think.
> Unity must show and search the letter(string) even it's not complete.
>
> Did you tried Google using Instant Search(default setting)?
> Google Instant Search show and search with whole incomplete string even you didn't enter, space, type next character and so on.
> As you see attached image from Koichi, there's 4 letters but not completed.
> Google start to search it using 4 letters, but Unity didn't try to search it.

No, Google Instant search behaves the same, because the input method
engine (ibus in this case) does not submit the string to the application
(the browser in the case of Google) until you tell it to do so (by
pressing Space or Enter).
In your case, Google starts to search on the first three letters, since
the forth one has not been submitted to the browser yet, so Google
cannot know about it. It can only guess.

What you want is a feature request, not a bug. And it's not Unity's
fault, but the input method engine and more importantly the input method
modules we use are not designed for this. There are possibilities to
have the same behavior, however, at least for Chinese: use one of the
ibus-table-* input methods, which are the old style input methods, where
you have to select every single character and submit them separately to
the application. By doing this, you can have the same function: Unity
begins to search with the first character. But most Chinese users
nowadays don't want to select every single character manually any more,
but enjoy the intelligent input methods which detect and assemble the
complete sentence with their internal logic.

> Yes, I know CJK users "can" search with CJK letters and input method.
> But it's really annoying to press lots of keys for find 2 letters or press enter several times.
> Also, it's too unfamiliar to people who use Unity first.
> Because Windows and Mac doesn't have this problem it can even make Ubuntu's first impression bad!
>
> Please consider this bug one more time.

No, it's not Ubuntu's fault. The input methods we use are not designed
for this, on any Linux distribution. The input methods on Windows and
Mac work differently than the ones we are using.

You may want to submit a feature request to upstream ibus, and more
specifically to the intelligent input methods, like ibus-pinyin,
ibus-sunpinyin, ibus-chewing and ibus-anthy (and maybe others), if you
really care about this issue. I'm not sure however, if other Chinese and
Japanese users agree with you. ;)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJOZQQtAAoJENiwmJtstTzsPpkQALBKlbLTDLuGoqAyW38WtjHu
MK1XRyip7gpg5Si/kR0HpfcTlq6oxxAkPz22YTiZ76wXIUBFTHjz7XTMmEPj9eA/
onfw+n4EsB9JzM4ukz6vIGsSTMwnapjmogtq2c1ytFKCOUzM/V1RZKZb1StZxzcb
7YEZ6Esq+bS2uiJXujdeUyWNSok5Bc4+zxmtxH3urt7Tc6vOwTdVGHtiriWyqv42
cO/w3WiIVraJ7jbjSOhCFp/axznq7xca03+nyDji9M/MJKp7IACv6soMAU5xq9D4
pjTZjug7XLgcQKny4D1K/QAW1zoiw...

"I tested it with the latest version on Oneiric and it works like
expected. The pre-edit stuff appears in the search field, so you can see
what you type." @ Arne

 I can't show pre-edit words.
The following things are its environment:

ibus: 1.3.99.20110419-1ubuntu3
ibus-anthy: 1.2.6-2ubuntu1
unity: 1.2.6-2ubuntu1

I can show on Unity"2D", but cannot show on Unity"3D"

@Arne, @vbk, @jincreator

I test with my test environments, the pre-edit stuff could not appears in the search field with ibus-anthy (other ibus IMengines are not tested). It is strange, so I want to re-examine that behavior.

@Arne, could you please show your ibus/unity 's packages versions?

@vbk, @jincreator, could you re-test below?

-------------------------------------------------------------------
1) Open dash (with [windows] key).
2) Activate ibus (with [Ctrl]+[Space] key-sequence).
3) Type "arigatou"

Actual results in my environment:
 Do not show pre-edit text "ありがとう".

Expected results (or Arne's environment):
 Pre-edit text are show in search field?
-------------------------------------------------------------------

# But I don't know, maybe another bug?

The situation hito written is same with mine.
While I am typing pre-edit texts, the cursor doesn't move and '検索' ('Search' in English) is not hidden.
When I type Enter, edited text will be appeared.

My environment is wrong, sorry:

ibus: 1.3.99.20110419-1ubuntu3
ibus-anthy: 1.2.6-2ubuntu1
unity: 4.12.0-0ubuntu2

@jincreator comment #72

> *Chinese
> @Ding said he tested with ibus.
> I tested with ibus-pinyin, and it seems pressing arrow keys(Chinese letters are listed, and selected by number or arrow) sometines go to Unity, sometimes go to ibus.
ex) 你 : type ni > show list pronounced ni (你泥尼妮拟...) > select with number key(in this time, 1) or arrow & space
I'm, not Chinese so I'm wondering it's a problem or not.

You are talking about the character selection if I understand correctly, this usually happens when you are trying to input single character. We mostly input pinyin combination for characters or words.

Other than that, I update the unity to 4.12.0-0ubuntu2, ibus can be activated from dash, but if you are trying to search application (e.g. 浏览 which means browse), the dash gives you Firefox browswer which contain 浏览 words, but also eog. I wonder how does eog being searched.

(and when I'm trying to save the screenshot which has Chinese character, the filename is not correct, which Chinese character being encoded )

I use ibus-unikey to type vietnamese. The pre-edit text can't be shown on dash too until I press enter or ctrl. (This's is also a problem in gnome-shell when chatting from the "pop-up" at the bottom of the screen).

Test environment:
   Simplified Chinese
   ibus-pinyin 1.3.99.20110706-1
   unity 4.12.0-0ubuntu2

Test steps
1. click Dash
2. turn on Pinyin in the search field
3. type "DA", the character selection menu will show "1. 打, 2.大, 3.达, 4. 答,..."
4. press "Down" key in order to select the forth character "答", but the selection moves to dash application menu.

@Arne
I attached a picture showing difference between Unity and Google on Firefox.
Also I don't know about programming using iBus, and actually I never seen any programs support it perfect(gnome-shell, synapse. gnome-do, goldendict, ...).
But anyway Google on Firefox with "iBus" works well.
And I tested with some more internet search engine.
Is Google(+more) depends on javascript, not iBus?

@Fumihito
For now, Oneiric system is out of my hand because of personal reason.
So, I coudn't test it. Sorry.
But that's the exactly same result with ibus-hangul(iBus Korean Engine) and thus I guess it will happened to me, too.

@Kevin
That's what I want to say about with ibus-pinyin!
Thank you for describe perfect.

@Ray
I was talking about what Kevin said.
Anyway thank you for giving details about Chinese input.
And about eog...is it same with Bug 745243?

<attachment picture description>

Test 1
-------------------------------------------------------------------
1. Use ibus-hangul.
2. Open Unity Search.
3. Type "감"(type "rka" if you are using QWERTY with Dubeolsic(ibus-hangul default setting)).

Result
-> Nothing at search filed.
Actual Result
-> When type "ㄱ"(r), show letter "ㄱ" with highlighted and searching text "ㄱ"
-> After type "ㅏ"(k), show letter "가" with highlighted and searching text "가"
-> Later type "ㅁ"(a), show letter "감" with highlighted and searching text "감"

Test 2
-------------------------------------------------------------------
1. Starting after Test 1 with no more pressing key/mouse.
2. Type "사"(type "tk").

Result
-> Show only "감", typed at Test 1, and searching text "감".
Actual Result
-> When type "ㅅ"(t), show letter "감ㅅ" with "ㅅ" highlighted and searching text "감ㅅ"
-> After type "ㅏ"(k), show letter "감사" with "사" highlighted and searching text "감사"

Test 3
-------------------------------------------------------------------
1. Starting after Test 1 with no more pressing key/mouse.
2. Click background to hide Unity Search.
2. Re-open Unity.

Result
-> Show "사", typed at Test 2, and searching text "사"
Actual Result
-> Unity Search must be initialized with no text.

Test 4
-------------------------------------------------------------------
1. Open Google with Firefox and make sure Google Instant Search is on.
2. Type "감ㅅ"(type "rkat").

Result(=Actual Result)
-> When type "ㄱ"(r), show letter "ㄱ" with highlighted and searching text "ㄱ"
-> After type "ㅏ"(k), show letter "가" with highlighted and searching text "가"
-> Later type "ㅁ"(a), show letter "감" with highlighted and searching text "감"
-> Finally type "ㅅ"(t), show letter "감ㅅ" with "ㅅ" highlighted and searching text "감ㅅ"

Test 5
-------------------------------------------------------------------
1. Starting after Test 4 with no more pressing key/mouse.
2. Type "ㅏ"(type "k").

Result(=Actual Result)
-> Show letter "감사" with "사" highlighted and searching text "감사"

Conclusion
-------------------------------------------------------------------
Wether iBus has lack of return latest typing letter, there are 2 problem in Unity.
First, it must show what JK users are typing(although it's impossible to search with typing letter).
Second, it must flush every letters after Unity Search closed.

As othres says, it seems that current unity does not render pre-edit text.

I create patch to re-render text on pre-edit text changed.
https://code.launchpad.net/~cosmos-door/unity/fix-preedit-663776

This patch is working correctly in my environment (Japanese with ibus-anthy).
But I didn't test other environment (Chinese/Korean, and ibus-pinyin/ibus-skk...).

If you can build unity from source, please try it.

Hello, Mitsuya

I tried it on ibus-anthy, ibus-skk and ibus-mozc with your patch.
It works fine! Pre-edit texts are shown now.

It can't show the background for selecting segments.
But I think it is not a critical problem because we will not type long texts.
Step to repro (for mozc or anthy on Japanese environment)
1. type "gaikannnosettei"
2. it shows "がいかんのせってい"
3. press [space]
4. then, it will be converted to "外観の設定"
5. if you want to convert it to "概観の設定" or "外環の設定" or ..., it is difficult because you can't find selected segment.

The iBus integration is still an issue.

Test environment:
Unity: 4.20.0-0ubuntu2
iBus: 1.3.99.20110419-1ubuntu3
ibus-pinyin: 1.3.99.20110706-1

Test steps:
1. Click dash icon
2. CTL-space to switch to pinyin IM
3. Type "zhong" in search menu

Expected to see a character selection window, but the selection window disappeared.

4. continue to test. press"back space", the character selection window appeared. press "back space" one more time, the character selection window disappeared again.

I filed bug 867885 with the information from comment #85, let's track it there.

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