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.
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.
*** Bug 1119047 has been marked as a duplicate of this bug. ***
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.
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.
> 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.
> 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.
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.
(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?
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.
(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.
> 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?
(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?
(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.
> 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.
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
(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.
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.
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.
(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.
(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.)
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.
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.