Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement Request: making initial mode customizable for ibus-mozc #201

Closed
GoogleCodeExporter opened this issue Apr 22, 2015 · 40 comments
Closed

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

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

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

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

(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
Copy link
Author

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
Copy link
Author

> 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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

Issue 238 has been merged into this issue.

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

1 similar comment
@GoogleCodeExporter
Copy link
Author

Issue 238 has been merged into this issue.

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

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

  • Changed state: VolunteersNeeded

@GoogleCodeExporter
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

Original comment by yukawa@google.com on 21 Apr 2015 at 6:15

@ckolivas
Copy link

Many of us depended on the default behaviour of starting in hiragana mode and now I'm unable to find a meaningful way to configure it to go to hiragana mode by default which means every time I switch input methods I also have to select hiragana from the system tray (on the few remaining desktop environments where it still works). How is this progress? How do we restore the original behaviour?

@yukawa
Copy link
Collaborator

yukawa commented May 21, 2015

Unfortunately there is no update since no one has volunteered to work on that. That's actually one of the the reasons why we decided to deprecate ibus-mozc (#287). I wish I could help, but I'm unable to spend as much time with ibus-mozc anymore as I'm also in charge of many projects such as Chromium and Android as well as other clients of Mozc such as Mozc for Android and Mozc for Windows.

If you wish to change the default behavior to the original one, I would do that if you could make a consensus among ibus-mozc maintainers in major Linux distributions (Fedora, Ubuntu, Debian, openSuse, Arch, Gentoo, ...). Please note that some people don't like the previous behavior as pointed out in the first post in this thread.

Also, as I pointed it out in my previous comment, you can change the behavior by modifying the source code and rebuild the binaries by yourself.
See src/unix/ibus/property_handler.cc Line 78 - 86

// 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 to replace const bool kActivatedOnLaunch = false; with const bool kActivatedOnLaunch = true; and rebuild the ibus-mozc binary.

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

Thank you for your understanding.

@ckolivas
Copy link

Thanks for responding. Ubuntu is defaulting to direct input which is the problem for me. As ibus-mozc is being deprecated I shall return to using ibus-anthy which defaults to hiragana, thank you.

@yukawa
Copy link
Collaborator

yukawa commented May 21, 2015

Just for your reference, Ubuntu 15.10 is supposed to start using Fcitx rather than ibus as their default input method (input method framework), which is another reason for me to hesitate to spend my time to improve ibus-mozc. Probably fcitx-mozc would be in far better situation than ibus-mozc in terms of maintenance resources.

See following pages about the direction of Ubuntu.

@hanaokaiwa
Copy link

I am wondering why ibus-mozc behaves deferently as fcitx-mozc.
Which behavior should be right? How ibus-anthy and fcity-anthy behaves as default?
ibus-mozc's behavior now is just because somebody requests this. But I request for default method of HIRAGANA and I think more people request the same than who requests for default of DIRECT.

@yukawa
Copy link
Collaborator

yukawa commented Aug 1, 2016

ibus-mozc's behavior now is just because somebody requests this. But I request for default method of HIRAGANA and I think more people request the same than who requests for default of DIRECT.

I do understand you frustration, but the behavior change was actually based on recommendation by ibus core committer and ibus-mozc package maintainers of multiple Linux distributions (AFAIK package maintainers in openSUSE and Ubuntu preferred this default behavior). It's not a random somebody at all. So if you really think we should change the behavior again, let me reiterate my previous comment.

If you wish to change the default behavior to the original one, I would do that if you could make a consensus among ibus-mozc maintainers in major Linux distributions (Fedora, Ubuntu, Debian, openSuse, Arch, Gentoo, ...).

So please reach out ibus-mozc package maintainers of major Linux distributions to make a consensus to do that. If they (or most of them) agree to change the behavior, I'm happy to do that (if ibus-mozc is not removed from our repository yet. See #287 for details. Basically our plan is to discontinue the support of ibus some time soon)

@hanaokaiwa
Copy link

Thank you very much for your reply.
I just upgraded my Fedora and it took too much time for me to modify ibus-mozc's source code and rebuild the package.
Thank you very much for your explain. I know it is very difficult to change the behavior of ibus-mozc now. Thank you.

@Dreamsorcerer
Copy link

Just for your reference, Ubuntu 15.10 is supposed to start using Fcitx rather than ibus as their default input method (input method framework), which is another reason for me to hesitate to spend my time to improve ibus-mozc. Probably fcitx-mozc would be in far better situation than ibus-mozc in terms of maintenance resources.

Did something change? I'm now on Ubuntu 20.04 and this is still an issue, it still seems to use ibus-mozc, and even if I install fcitx-mozc, it doesn't change anything.

@ftake
Copy link
Contributor

ftake commented Mar 14, 2021

Now we have a user config file for ibus-mozc. So I think we can resolve this issue.

@Dreamsorcerer
Copy link

Great, is there some documentation for this? Has it just been added, or is this already available (e.g. in Ubuntu 20.04)?

@ftake
Copy link
Contributor

ftake commented Mar 15, 2021

Sorry for my misleading comment. We still need some code to resolve this.

@Dreamsorcerer
Copy link

Ah, I see what you mean now. No problem.

@ftake
Copy link
Contributor

ftake commented Mar 16, 2021

I've started PoC.
https://github.com/ftake/mozc/commits/feature/initial-composition-mode
This code is not tested at all for now.

You will be able to customize activated_on_launch and initial_composition_mode with ~/.mozc/ibus_config.textproto

@ftake
Copy link
Contributor

ftake commented Mar 17, 2021

It looks working as expected

For example, if you want to activate ibus-mozc with full Katakana mode, write following lines in that file.
By omitting initial_composition_mode, the initial mode becomes HIRAGANA.

activated_on_launch : true
initial_composition_mode : FULL_KATAKANA

@Nocifer
Copy link

Nocifer commented Mar 18, 2021

Well, how very nice that after months and months of getting annoyed with this issue, I finally decide to come here and make a report about it, only to find that someone has just implemented a patch to solve it :)

The patch does work very nicely, and IMHO this should be the default behavior of Mozc. But, even though for my needs it's perfectly adequate as it stands, to really become complete it needs two more things: the first is of course to expose it in the GUI (instead of having to edit ibus_config.textproto) and the second is to make it so that whenever the user changes the input mode manually, Mozc will optionally remember this choice and set it as the new default for subsequent sessions.

hiroyuki-komatsu added a commit that referenced this issue Mar 20, 2021
BUILD=4317
* #201

Default ~/.config/mozc/ibus_config.textproto
```
engines {
  name : "mozc-jp"
  longname : "Mozc"
  layout : "default"
  layout_variant : ""
  layout_option : ""
  rank : 80
}
active_on_launch: False
```

Sample configuration
```
engines {
  name : "mozc-jp"
  longname : "Mozc"
  layout : "ja"
  layout_variant : ""
  layout_option : ""
  rank : 80
}
active_on_launch: True
```
@hiroyuki-komatsu
Copy link
Collaborator

Thank you very much Fuminobu for your suggestion and proof-of-concept.

As you suggested 467a91c enabled to configure the initial state on launch.
The implementation is different from your POC, but the concept is equivalent.

Default ~/.config/mozc/ibus_config.textproto

engines {
  name : "mozc-jp"
  longname : "Mozc"
  layout : "default"
  layout_variant : ""
  layout_option : ""
  rank : 80
}
active_on_launch: False

Sample configuration

engines {
  name : "mozc-jp"
  longname : "Mozc"
  layout : "ja"
  layout_variant : ""
  layout_option : ""
  rank : 80
}
active_on_launch: True

Sample configuration #2

engines {
  name : "mozc-jp"
  longname : "Mozc"
  layout : "ja"
  layout_variant : ""
  layout_option : ""
  rank : 80
}
engines {
  name : "mozc-us"
  longname : "Mozc US"
  layout : "us"
  layout_variant : ""
  layout_option : ""
  rank : 80
}
active_on_launch: True

You may need to run ibus restart after the modification.

@ftake
Copy link
Contributor

ftake commented Mar 21, 2021

Thank you.
I'm very happy for making this customizable because I suggested turning the default mode to IME off for IBus 1.5, 6 years ago.

@Orzelius
Copy link

Can I configure this on Windows (google Japanese input) somehow or I have to build and install Mozc on its own?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants