Bug 1119967

Summary: ibus-mozc could not save input mode
Product: [Fedora] Fedora Reporter: Daniel <danielsun3164>
Component: mozcAssignee: Akira TAGOH <tagoh>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: abetakehiko, chorn, i18n-bugs, mfabian, tagoh, tfujiwar, yukawa
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-29 21:36:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
The simplest input source configuration for monolingual Japanese users none

Description Daniel 2014-07-16 02:49:43 UTC
Description of problem:
After a recent update of ibus-mozc, it could not save input mode I set.

Version-Release number of selected component (if applicable):
$ rpm -q mozc ibus-mozc
mozc-1.15.1814.102-1.fc20.x86_64
ibus-mozc-1.15.1814.102-1.fc20.x86_64

How reproducible:
Everytime

Steps to Reproduce:
1. Activate mozc input method in ibus.
2. The default input mode is "Direct input", change it to "Hiragana"
3. Restart ibus and activate mozc input method again, the input mode changed back to "Direct input" again

Actual results:
The input mode of mozc input method changed back to "Direct input".

Expected results:
Because I set the input method to "Hiragana" before, the input mode should be saved and be still "Hiragana".

Additional info:
If it is difficult to save the input mode, the default input mode should be "Hiragana" because most people would not activate mozc input method to simply input English.

Comment 1 Yohei Yukawa 2014-07-20 15:19:34 UTC
Hi Daniel.

In fact this is an intentional change based on some feedback.  I decided to optimize the initial mode for monolingual users, though I know that the latest behavior is not optimized for multilingual users.

Please refer to the following threads for the background discussions.

https://code.google.com/p/mozc/issues/detail?id=201
https://code.google.com/p/mozc/issues/detail?id=238

If you prefer the previous behavior, you can change the initial mode as I commented here.
https://code.google.com/p/mozc/issues/detail?id=201#c19

It would be nice if the initial mode was configurable, but I don't have enough spare time to work on ibus-mozc nowadays.  I might accept patches to make this configurable, so long as they are reasonable.

Thank you for your understanding.

Comment 2 Takehiko Abe 2014-07-21 15:16:29 UTC
*** Bug 1119047 has been marked as a duplicate of this bug. ***

Comment 3 Takehiko Abe 2014-07-21 15:39:24 UTC
mozc is an input method for Japanese text. Setting direct input mode as
its default does not make much sense imo.

And I do not quite get the point of the issue 201 (enhancement request).

ibus remembers the input source I used in a previous session. For
instance, if I end my gnome session in 'en', ibus will start with 'en'
next time.

Comment 4 Yohei Yukawa 2014-07-21 16:44:45 UTC
Hi Takehiko.
I understand your opinion, but at least one of IBus core developers seems to be suggesting the current behavior.

https://code.google.com/p/ibus/issues/detail?id=1662#c1
> After  Issue 1659  is fixed, I'm thinking we don't need xkb engines for ja and
> personally I think the initial mode can be Eisu mode permanently.

I feel most of confusions came from so frequent UX changes in IBus upstream.  It's really sad, and it makes me less motivated to maintain ibus-mozc.  Nowadays I'd like to spend my spare time on improving Mozc on other platforms like Windows and Android rather than keeping up with never-ending UX changes in IBus.

Maybe I'd suggest you to switch from ibus-mozc to ibus-kkc, which has been actively developed by Fedora people.  Actually, one of the goal of ibus-kkc is to be a a better replacement of ibus-mozc and ibus-anthy, according to the Fedora wiki.
http://fedoraproject.org/wiki/Features/libkkc
It would be nice if your feedback is used to ibus-kkc.

Thanks again for your understanding.

Comment 5 Takehiko Abe 2014-07-22 14:17:59 UTC
> I understand your opinion, but at least one of IBus core developers seems to be
> suggesting the current behavior.
> 
> https://code.google.com/p/ibus/issues/detail?id=1662#c1
>> After  Issue 1659  is fixed, I'm thinking we don't need xkb engines for ja and

(D'oh! Is that the "Japanese" input source that does not do japanese?
I remember I was puzzled by it. I think I'm getting why it is there
now.  Why not removing direct input mode instead? It's redundant. but
i digress)

>> personally I think the initial mode can be Eisu mode permanently.

But WHY?

The post does not explain why he thinks Direct Input mode is better
default than Hiragana. I looked around but did not find anything
concrete.

Why do you think Direct input mode is a better choice? 

> I feel most of confusions came from so frequent UX changes in IBus upstream. 
> It's really sad, and it makes me less motivated to maintain ibus-mozc. 
>
> Nowadays I'd like to spend my spare time on improving Mozc on other platforms
> like Windows and Android rather than keeping up with never-ending UX changes in
> IBus.

I'm sorry to hear that. It's depressing.

Comment 6 Yohei Yukawa 2014-07-22 17:11:55 UTC
> Why do you think Direct input mode is a better choice?

Please ask him.  But I suppose that IBus developers no longer want to handle tricky requirements from Japanese input method users in IBus side.

For example, please try to assign Ctrl+J to switch to Hiragana mode of Mozc from any other input source that does not belong to Mozc.  According to the following thread, it is still unable.
https://code.google.com/p/ibus/issues/detail?id=747

This is one of the examples why the weird Direct mode of Mozc is still required.  If the Direct mode belongs to Mozc, it is easy for Mozc engine to implement those functionalists because all key events are forwarded to Mozc engine even in Direct mode.  But if we remove the Direct mode from Mozc, you simply lose existing functionality until IBus issue 747 is resolved.  Even if IBus issue 747 is resolved, you are likely to need to customize Ctrl+J in IBus settings, not in Mozc's one.  I'm not sure if it is really useful and understandable for users.

Hope this helps you to understand the current situation.

Comment 7 fujiwara 2014-07-23 02:43:07 UTC
I think almost Japanese used to use English and Japanese by default and it would be a cost to switch US xkb engine and Japanese IM engine. Since Japanese IM engines provide the direct mode and Hiragana mode, one IME can provide the English and Japanese.
Also this way can simplify the default trigger key by engine. Japanese is Zenkaku_Hankaku, Korean is Alt_R and Chinese is Ctrl+space.

However I'm still not sure if the direct mode is the best by default.
In MS-Windows the default is Hiragana and a few web search engines enable Hiragana by default.
And then I think the default Hiragana is still valid for the GUI users.

In Windows 8, Japanese enables one MS-IME only by default and the trigger key is Zenkaku_Hankaku only. Chinese enables US layout and MS-IME by default and Super+space can switch the two engines but also Ctrl+space can switch the modes.

Comment 8 Takehiko Abe 2014-07-23 08:22:29 UTC
(In reply to Yohei Yukawa from comment #6)
>> Why do you think Direct input mode is a better choice?
> 
> Please ask him.  But I suppose that IBus developers no longer want to handle
> tricky requirements from Japanese input method users in IBus side.
> 
> For example, please try to assign Ctrl+J to switch to Hiragana mode of Mozc
> from any other input source that does not belong to Mozc.  According to the
> following thread, it is still unable.
> https://code.google.com/p/ibus/issues/detail?id=747

While the discussion is informative and interesting, it has little to
do with why direct input mode should be the default. (am i missing something?)

> This is one of the examples why the weird Direct mode of Mozc is still
> required.

I see. It is required. But why should it be the default mode?

Comment 9 Yohei Yukawa 2014-07-23 13:24:32 UTC
Created attachment 920224 [details]
The simplest input source configuration for monolingual Japanese users

For most of monolingual Japanese users, the simplest input source configuration is just have one Japanese input method which has Direct input mode as well as Hiragana mode.  In this configuration, some users prefer the input method to start with Direct input mode rather than Hiragana mode.  In ibus-anthy and ibus-kkc, the default input mode is configurable, which is indeed useful in this configuration.

Comment 10 Yohei Yukawa 2014-07-23 13:42:01 UTC
(In reply to Takehiko Abe from comment #8)
> (In reply to Yohei Yukawa from comment #6)
> >> Why do you think Direct input mode is a better choice?
> > 
> > Please ask him.  But I suppose that IBus developers no longer want to handle
> > tricky requirements from Japanese input method users in IBus side.
> > 
> > For example, please try to assign Ctrl+J to switch to Hiragana mode of Mozc
> > from any other input source that does not belong to Mozc.  According to the
> > following thread, it is still unable.
> > https://code.google.com/p/ibus/issues/detail?id=747
> 
> While the discussion is informative and interesting, it has little to
> do with why direct input mode should be the default. (am i missing
> something?)

I've attached a screenshot in comment #8, which I suppose explains when and why people expect Mozc to start with Direct input mode. Actually this configuration is almost equivalent to the default configuration on Windows Japanese edition, where the default input mode is Direct except for Windows 8.

Interestingly Microsoft IME changed the default input mode to Hiragana instead of Direct in Windows 8, then changed the default mode back to Direct in Windows 8.1, probably because of lots of negative feedback.

Comment 11 Takehiko Abe 2014-07-23 15:04:21 UTC
> I've attached a screenshot in comment #8, which I suppose explains when and why
> people expect Mozc to start with Direct input mode.

Um. Sorry. No. It does not. It just shows a configuration where mozc is the
only input source enabled. How does it explain why direct input mode
should be the default?

Comment 12 Yohei Yukawa 2014-07-23 15:51:00 UTC
(In reply to Takehiko Abe from comment #11)
> > I've attached a screenshot in comment #8, which I suppose explains when and why
> > people expect Mozc to start with Direct input mode.
> 
> Um. Sorry. No. It does not. It just shows a configuration where mozc is the
> only input source enabled. How does it explain why direct input mode
> should be the default?

OK. Please follow the following steps to reproduce the issue.

1. Make sure Mozc is only the selected input source, like the attached the screenshot.
2. Log out
3. Log in again.
4. Open any application where you can type something.
5. Hit any key.

Expected behavior (for people like the reporter of Mozc Issue 201):
At step 5, when you hit 'I' key, 'i' is input instead of 'い'

Actual behavior (in ibus-mozc-1.13.1651.102-1.fc20 and prior)
At step 5, when you hit 'I' key, 'い' is input instead of 'i'

How I fixed this issue:
Change the default input mode of Mozc from Hiragana to Direct, based on the discussion in Mozc Issue 201.
https://code.google.com/p/mozc/issues/detail?id=201

Does it make sense?

Comment 13 fujiwara 2014-07-24 03:14:49 UTC
(In reply to Yohei Yukawa from comment #10)
> Interestingly Microsoft IME changed the default input mode to Hiragana
> instead of Direct in Windows 8, then changed the default mode back to Direct
> in Windows 8.1, probably because of lots of negative feedback.

Thank you for that info. I didn't know Windows 8.1.

I had some discussions about mono IME.
I think one IME is useful for Japanese by default however it seems Chinese users like to switch US layout and some Chinese IMEs and then it seems the mono IME is a special request for Japanese and Korean.
Currently ibus-hangul has no mode and under the discussion.
Now both ibus and gnome configures XKB engines and IM engines by default and if users wish the mono IME, they need to delete the loaded XKB engines by manual.
I've been thinking the better implementation but basically ibus upstream does not agree with the language specific patch for ibus core.

Comment 14 Takehiko Abe 2014-07-24 03:59:04 UTC
> OK. Please follow the following steps to reproduce the issue.
> 
> 1. Make sure Mozc is only the selected input source, like the attached the
> screenshot.
> 2. Log out
> 3. Log in again.
> 4. Open any application where you can type something.
> 5. Hit any key.
> 
> Expected behavior (for people like the reporter of Mozc Issue 201):
> At step 5, when you hit 'I' key, 'i' is input instead of 'い'

err. What if he wants to type 'い' instead of 'i'?

> Actual behavior (in ibus-mozc-1.13.1651.102-1.fc20 and prior)
> At step 5, when you hit 'I' key, 'い' is input instead of 'i'

Step 6. hit his preferred hotkey to switch to direct input
mode and type 'i' again.

I see nothing to be fixed here.

It is pretty common to realize you are in a wrong mode after
you typed a few chars and have to start over.

Comment 15 Takehiko Abe 2014-07-24 04:06:27 UTC
One more

> How I fixed this issue:
> Change the default input mode of Mozc from Hiragana to Direct, based on the
> discussion in Mozc Issue 201.
> https://code.google.com/p/mozc/issues/detail?id=201

Issue 201 is titled:

    Enhancement Request: making initial mode customizable for
    ibus-mozc

Not: 

    Set default to direct input mode

Comment 16 Yohei Yukawa 2014-07-24 04:08:40 UTC
(In reply to Takehiko Abe from comment #15)
> One more
> 
> > How I fixed this issue:
> > Change the default input mode of Mozc from Hiragana to Direct, based on the
> > discussion in Mozc Issue 201.
> > https://code.google.com/p/mozc/issues/detail?id=201
> 
> Issue 201 is titled:
> 
>     Enhancement Request: making initial mode customizable for
>     ibus-mozc
> 
> Not: 
> 
>     Set default to direct input mode

This is why its status is now VolunteersNeeded.

Comment 17 Takehiko Abe 2014-07-24 04:16:01 UTC
one more again

(ok i'm little frustrated)

so far nobody put forth the straightfoward explanation why the direct input mode
is better default. just two indirect reasons has been presented:

1. some users somewhere want that way
2. microsft windows japanese edition setup that way

i must say both are pretty weak and vague.

Comment 18 Yohei Yukawa 2014-07-24 05:12:20 UTC
Year.  Me too.  I'm a little tired to discuss ibus-mozc, which I'm no longer interested in.  I made that patch which changes the default input mode 9 months ago (see the date of Issue 201).  If I changed the default mode again, I bet I will be asked by someone else to change the default mode back to Direct mode from Hiragana mode, in 9 months or so.  I guess this battle continues until someone provides a nice patch for ibus-mozc to make the initial mode customizable.

In case you overlooked it, you can change the initial mode of ibus-mozc if you don't hesitate to apply local modification and rebuild and replace ibus-mozc package with your own one.
https://code.google.com/p/mozc/issues/detail?id=201#c19

I really appreciate your understanding and patience.

Comment 19 Yohei Yukawa 2014-07-24 15:38:49 UTC
(In reply to Takehiko Abe from comment #14)
> > OK. Please follow the following steps to reproduce the issue.
> > 
> > 1. Make sure Mozc is only the selected input source, like the attached the
> > screenshot.
> > 2. Log out
> > 3. Log in again.
> > 4. Open any application where you can type something.
> > 5. Hit any key.
> > 
> > Expected behavior (for people like the reporter of Mozc Issue 201):
> > At step 5, when you hit 'I' key, 'i' is input instead of 'い'
> 
> err. What if he wants to type 'い' instead of 'i'?

If he wants so, he should modify the unix/ibus/property_handler.cc, as commented in Comment #1,
or put add more step like:
  Step 6. hit his preferred hotkey to switch to Hiragana input mode and type 'i' again if he wants to type 'い' instead of 'i'.

> > Actual behavior (in ibus-mozc-1.13.1651.102-1.fc20 and prior)
> > At step 5, when you hit 'I' key, 'い' is input instead of 'i'
> 
> Step 6. hit his preferred hotkey to switch to direct input
> mode and type 'i' again.
> 
> I see nothing to be fixed here.
> 
> It is pretty common to realize you are in a wrong mode after
> you typed a few chars and have to start over.

Yes it is pretty common annoyance, but some people tend to get super frustrated if it *always* and *predictably* happens every time when they log-in, especially for those who always launch terminal or their favorite editor immediately after log-in.  On the other hand, I know there are some people who wish exactly the opposite.  I got such feature requests at least 3 times when I was mainly working on Google Japanese Input for Windows.
https://productforums.google.com/d/msg/ime-ja/1a0cvu4nQA4/M9l5pDyMWQ8J
https://productforums.google.com/d/msg/ime-ja/eEOUmKKKmDU/ImiSrccx6qMJ
https://productforums.google.com/d/msg/ime-ja/NSKNGHme-6g/1OMTp83h5r4J

And probably some people feel that the previous mode should be remembered. like Mac OS X, right?

Well, I feel these 3 options are equally reasonable, and equally unreasonable for those who have different preference.  It is quite understandable that ibus-kkc and ibus-anthy enable users to choose the initial input mode in their setting dialogs.  This is why I suggested you to switch to ibus-kkc in Comment #4.

As for Mozc / Google Japanese Input, I think the same feature should be supported, but nowadays I don't have enough time to do it, because I changed my main project  last January thus I'm no longer working on Mozc as a full time developer.  I'm now contributing to Mozc / Google Japanese Input project just as one volunteer.  This is why I didn't close Issue 201 as Fixed but keep it Open as VolunteersNeeded.

Comment 20 Takehiko Abe 2014-07-25 02:30:37 UTC
(In reply to Yohei Yukawa from comment #19)
>> It is pretty common to realize you are in a wrong mode after
>> you typed a few chars and have to start over.
>
> Yes it is pretty common annoyance, but some people tend to get super
> frustrated if it *always* and *predictably* happens every time when
> they log-in,

They are being unreasonablly sensitive. Please ignore them.

> especially for those who always launch terminal or their favorite
> editor immediately after log-in. On the other hand, I know there are
> some people who wish exactly the opposite.

What I want is not the opposite.

> [...]
>
> And probably some people feel that the previous mode should be
> remembered. like Mac OS X, right?

In Mac OS X, I believe you can switch directly to a specific input
mode. So which being default is irrelevant there. (whereas we cannot
do that with ibus as you previously mentioned.)

> Well, I feel these 3 options are equally reasonable, and equally
> unreasonable for those who have different preference.

Equally reasonable! You've just admitted that there's no solid
reason to choose direct input mode over hiragana mode as default.

Please note that they are equally reasonable only for those who use
mozc exclusively and switch back and forth between direct input mode
and hiragana mode.

I use 'en' to type ascii chars and switch to a japanese input method
to type japanese. When I switch to a japanese input method, I expect
that I am able to type Japanese. You broke this expectation. I have to
switch to mozc and then switch to hiranaga mode. This double action
feels very silly. It even feels buggy, too. I thought mozc crashed
when mozc was updated.

Since I know what is going on now, it is actually a minor, once per
session annoyance (read 'I am not super frustrated'). But it must be
confusing to those who are new to mozc.

> It is quite understandable that ibus-kkc and ibus-anthy enable users
> to choose the initial input mode in their setting dialogs. 

It is a good feature to have. But what should be the default is an
orthogonal issue. (hiragana should be the default obviously.)

Comment 21 Fedora End Of Life 2015-05-29 12:22:55 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 22 Fedora End Of Life 2015-06-29 21:36:20 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.