Enhancement Request: making initial mode customizable for ibus-mozc

[GoogleCodeExporter]

Recently, IBus developers are changing the design of IBus; they try to let 
users use Eisu input mode of ibus-anthy or ibus-mozc instead of Japanese 
keyboard engine (xkb:jp::jpn).

A problem is ibus-mozc always starts with Hiragana mode although many users 
expect that it starts with Eisu mode.

Is is possible to make the initial mode of Mozc customizable?

My proposal is that users can choose one from:
- Always Eisu
- Always Hiragana
- Start with the previous mode (Mac OS X-like behavior)
The third option allows to save the last input mode and restore it at the next 
session. It is useful to use ibus-mozc in both the new way above and the old 
way with xkb:jp::jpn.

ibus-anthy will support this feature.
http://code.google.com/p/ibus/issues/detail?id=1662

Original issue reported on code.google.com by f.takeya...@gmail.com on 24 Oct 2013 at 3:51

[GoogleCodeExporter]

Although I haven't tested, I guess you can start ibus-mozc in DIRECT mode as 
follows.

https://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/mozc_engine_pro
perty.cc?r=171#135
const commands::CompositionMode kMozcEngineInitialCompositionMode =
#if IBUS_CHECK_VERSION(1, 5, 0)
    commands::DIRECT;
#else
    commands::HIRAGANA;
#endif

https://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/property_handle
r.cc?r=171#74
PropertyHandler::PropertyHandler(MessageTranslatorInterface *translator,
                                 client::ClientInterface *client)
    : prop_root_(ibus_prop_list_new()),
      prop_composition_mode_(NULL),
      prop_mozc_tool_(NULL),
      client_(client),
      translator_(translator),
      original_composition_mode_(kMozcEngineInitialCompositionMode),
#if IBUS_CHECK_VERSION(1, 5, 0)
      is_activated_(false) {
#else
      is_activated_(true) {
#endif

As a first step, could you test if the above change satisfies your request?

Original comment by yukawa@google.com on 24 Oct 2013 at 4:29

[GoogleCodeExporter]

Oops, probably you should change |PropertyHandler::is_activated_| only.

https://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/property_handle
r.cc?r=171#74
PropertyHandler::PropertyHandler(MessageTranslatorInterface *translator,
                                 client::ClientInterface *client)
    : prop_root_(ibus_prop_list_new()),
      prop_composition_mode_(NULL),
      prop_mozc_tool_(NULL),
      client_(client),
      translator_(translator),
      original_composition_mode_(kMozcEngineInitialCompositionMode),
#if IBUS_CHECK_VERSION(1, 5, 0)
      is_activated_(false) {
#else
      is_activated_(true) {
#endif

Original comment by yukawa@google.com on 25 Oct 2013 at 1:40

[GoogleCodeExporter]

Note that *mode* of Mozc is a bit more complex than you might expect.  The 
internal state of ibus-mozc is actually a tuple of (bool, 
commands::CompositionMode), while a user observes "Mode Label" only.  The 
following table describes how each pair is mapped into "Mode Label".  (*1) is 
the current initial state of ibus-mozc.  "Eisu input mode" you mentioned 
actually corresponds to (*2).

| is_activated_ | original_composition_mode_ |       Mode Label      |
----------------------------------------------------------------------
|     true      |  commands::HIRAGANA        |  Hiragana             | (*1)
|     true      |  commands::FULL_KATAKANA   |  Katakana             |
|     true      |  commands::HALF_ASCII      |  Latin                |
|     true      |  commands::FULL_ASCII      |  Wide Latin           |
|     true      |  commands::HALF_KATAKANA   |  Half width katakana  |
|     false     |  commands::HIRAGANA        |  Direct input         | (*2)
|     false     |  commands::FULL_KATAKANA   |  Direct input         |
|     false     |  commands::HALF_ASCII      |  Direct input         |
|     false     |  commands::FULL_ASCII      |  Direct input         |
|     false     |  commands::HALF_KATAKANA   |  Direct input         |

Original comment by yukawa@google.com on 25 Oct 2013 at 2:59

[GoogleCodeExporter]

Hmm, ibus-mozc still starts with hiragana mode ("あ") though I tried both 
modifications.

> (*1) is the current initial state of ibus-mozc.
> "Eisu input mode" you mentioned actually corresponds to (*2).
I understand.
The symbol of (*1) is "あ" and the symbol of (*2) is "A" (not "_A").
# The behavior of direct input mode ("A") looks same as latin mode ("_A") in 
IBus 1.5.

Original comment by f.takeya...@gmail.com on 25 Oct 2013 at 5:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> Hmm, ibus-mozc still starts with hiragana mode ("あ") though I tried both 
modifications.

Sorry for taking your time.  I found that we need a bit more code to achieve 
your request.  Could you try the attached patch?  It seems to be working well 
on Ubuntu 13.10.

Original comment by yukawa@google.com on 25 Oct 2013 at 1:33

Attachments:

• mozc_issue_201_diff.patch

[GoogleCodeExporter]

Thank you. I also confirmed ibus-mozc start with Direct input mode though the 
property of ibus was not updated (it was still Hiragana).

# Initial mode of ibus-anthy have been already customizable.

Original comment by f.takeya...@gmail.com on 26 Oct 2013 at 7:53

[GoogleCodeExporter]

> Thank you. I also confirmed ibus-mozc start with Direct input mode though the 
property of ibus was not updated (it was still Hiragana).

Oops, reproduced on Fedora rawhide with the previous patch.  The new patch 
attached to this post should fix the icon issue too.  PTAL?

> # Initial mode of ibus-anthy have been already customizable.

Making something customizable through mozc_tool is not a trivial job.  
mozc_tool is used not only by ibus-mozc but also by emacs-mozc, uim-mozc, 
fcitx-mozc, Mozc client for IMM32 (on Windows), Mozc client for TSF (on 
Windows), and Mozc client for IMKit (on OSX).  In addition to that, we need to 
consider the portability of ~/.mozc/config1.db because users may want to use 
different *default* mode for each environment.

Original comment by yukawa@google.com on 27 Oct 2013 at 1:47

• Added labels: OpSys-Android, OpSys-Linux, OpSys-Windows

Attachments:

• mozc_issue_201_rev2.patch

[GoogleCodeExporter]

Original comment by yukawa@google.com on 27 Oct 2013 at 1:47

• Added labels: OpSys-OSX
• Removed labels: OpSys-Android

[GoogleCodeExporter]

The new patch works fine. I tested on openSUSE 12.3 + KDE + IBus 1.5.3 (with 
show-input-mode-icon.patch).

> Making something customizable through mozc_tool is not a trivial job
Now I think we need ibus-mozc configuration tool additionally to the existing 
property tool. This is because ibus-mozc will need to support selecting 
keyboard layouts as ibus-anthy does.

I have an idea (just workaround for now):
- specifying initial mode by a command line parameter of ibus-engine-mozc and 
registering two mozc engines to ibus; one starts with direct input mode and the 
other start with Hiragana mode

Original comment by f.takeya...@gmail.com on 28 Oct 2013 at 3:32

[GoogleCodeExporter]

(Narrowing down the scope to ibus-mozc.  Lowering the priority as announced in 
Issue 194)

> specifying initial mode by a command line parameter of ibus-engine-mozc and 
registering two mozc engines to ibus

Even though it's easy to add some command line parameter for ibus-engine-mozc 
to customize something, we are able to specify only one command line settings 
per IBus component.  See this example https://code.google.com/p/ibus/wiki/DevXML
Did I misunderstand your point?

Probably we need to treat some of properties ("setup" or something?) which are 
available in IBusEngineDesc as a marker to change the behavior of ibus-mozc.
http://ibus.googlecode.com/svn/docs/ibus-1.5/IBusEngineDesc.html#IBusEngineDesc-
-name
http://ibus.googlecode.com/svn/docs/ibus-1.5/IBusEngineDesc.html#IBusEngineDesc-
-setup

Original comment by yukawa@google.com on 29 Oct 2013 at 4:09

• Changed title: Enhancement Request: making initial mode customizable for ibus-mozc
• Added labels: Priority-Low
• Removed labels: OpSys-OSX, OpSys-Windows, Priority-Medium

[GoogleCodeExporter]

I have not tried yet, but we can install multiple ibus components like 
ibus-mozc.xml and ibus-mozc-hiragana.xml

I am not sure this patch is related, after run ibus restart, ibus-mozc seems 
not to work at all (I can type just alphabets) on GNOME. Once I switch to 
another engine and back to ibus-mozc, it starts to work correctly.

Original comment by f.takeya...@gmail.com on 1 Nov 2013 at 5:36

[GoogleCodeExporter]

> I have not tried yet, but we can install multiple ibus components like 
ibus-mozc.xml and ibus-mozc-hiragana.xml

In such case, multiple instances of ibus-engine-mozc can be spawned but I don't 
think the original author of ibus-engine-mozc considered such situation.  
Anyway, you can try it because mozc_server supports multiple clients as long as 
each client is properly implemented.

> I am not sure this patch is related, after run ibus restart, ibus-mozc seems 
not to work at all (I can type just alphabets) on GNOME. Once I switch to 
another engine and back to ibus-mozc, it starts to work correctly.

I'm not sure the 'restart' feature of IBus is documented and tested well now a 
days.  Is there any document and/or test cases in IBus upstream?  Is there any 
behavioral change between IBus 1.4 and IBus 1.5?

Original comment by yukawa@google.com on 2 Nov 2013 at 4:40

[GoogleCodeExporter]

Note: r185 didn't contain mozc_issue_201_rev2.patch because its branch was cut 
before the patch was committed.  mozc_issue_201_rev2.patch will be merged into 
the next release.

Original comment by yukawa@google.com on 5 Feb 2014 at 2:56

[GoogleCodeExporter]

ibus-mozc in r192 and later will start in DIRECT mode when running on IBus 1.5 
and later.

As for the ability to customize the initial mode only for ibus-mozc, let me 
close as WontFix. This is because:
1. In general, we don't want to introduce platform specific config options.
2. No one in Mozc team is actively working on ibus-mozc. ibus-mozc has been in 
maintenance mode and as announced as Issue 194.

If you want to make this happen, please file another feature request that is 
targeting for all the desktop platforms, not for ibus-mozc only.

Thanks again for your suggestion.

Original comment by yukawa@google.com on 16 May 2014 at 4:57

• Changed state: WontFix

[GoogleCodeExporter]

Issue 238 has been merged into this issue.

Original comment by yukawa@google.com on 12 Jul 2014 at 3:47

[GoogleCodeExporter]

Issue 238 has been merged into this issue.

Original comment by yukawa@google.com on 12 Jul 2014 at 3:47

[GoogleCodeExporter]

Hm, I wasn't aware of #201 but okay.

I'm surprised that people wanted Eisu (direct input) rather than Hiragana as 
the default.  Oh well, there doesn't seem to be a change of direction at this 
point.

Thanks!

Original comment by intermil...@gmail.com on 12 Jul 2014 at 4:26

[GoogleCodeExporter]

intermilan04@:
As of Mozc 1.15.1829.102 (r266), the simplest way to let Mozc launched with 
Hiragana mode is modifying the following code and then rebuilding Mozc.

https://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/property_handle
r.cc?r=251#78
> // Some users expect that Mozc is turned off by default on IBus 1.5.0 and 
later.
> // https://code.google.com/p/mozc/issues/detail?id=201
> // On IBus 1.4.x, IBus expects that an IME should always be turned on and
> // IME on/off keys are handled by IBus itself rather than each IME.
> #if IBUS_CHECK_VERSION(1, 5, 0)
> const bool kActivatedOnLaunch = false;
> #else
> const bool kActivatedOnLaunch = true;
> #endif  // IBus>=1.5.0

All you need to do is is to replace "kActivatedOnLaunch = false" with 
"kActivatedOnLaunch = true".

Perhaps we could do something suggested in comment #10 and #12, but at least I 
don't have enough spare time to handle it.  Feel free to contact me if you or 
someone you know is ready to be a responsible owner of this feature.

Thanks.

Original comment by yukawa@google.com on 12 Jul 2014 at 6:22

[GoogleCodeExporter]

Original comment by yukawa@google.com on 12 Jul 2014 at 6:23

• Changed state: VolunteersNeeded

[GoogleCodeExporter]

Original comment by yukawa@google.com on 12 Jul 2014 at 9:13