https://bugzilla.redhat.com/show_bug.cgi?id=2124835
Bug ID: 2124835 Summary: Input mode is reset by ibus restart Product: Fedora Version: 37 Status: NEW Component: ibus-anthy Assignee: tfujiwar@redhat.com Reporter: tagoh@redhat.com QA Contact: extras-qa@fedoraproject.org CC: i18n-bugs@lists.fedoraproject.org, shawn.p.huang@gmail.com, tagoh@redhat.com, tfujiwar@redhat.com Target Milestone: --- Classification: Fedora
Description of problem: When doing "ibus restart", the input mode in ibus-anthy is always reset to Hiragana. shouldn't it be held the previous state?
Version-Release number of selected component (if applicable): ibus-anthy-1.5.14-7.fc37.x86_64 ibus-1.5.27-1.fc37.x86_64
How reproducible: always
Steps to Reproduce: 1.change Input mode to something except Hiragana (e.g. Katakana, Eisu) 2.run "ibus restart" 3.
Actual results: Input mode is reset to Hiragana
Expected results: Input mode should be same to what changed at 1.
Additional info:
https://bugzilla.redhat.com/show_bug.cgi?id=2124835
--- Comment #1 from fujiwara tfujiwar@redhat.com --- I think resetting the input mode is good. If the default input mode is Hiragana, I assume the users would switch Anthy Hiragana and XKB JP. If the default input mode is Eisu, I assue the users would switch Anthy Eisu and Hiragana.
The default input mode can be saved with ibus-anthy setup dialog.
https://bugzilla.redhat.com/show_bug.cgi?id=2124835
--- Comment #2 from Akira TAGOH tagoh@redhat.com --- That may be something in question. I just wonder why we have such special state and make it complicated. In fact, MS-IME and mozc doesn't have two input states. they have only one to keep what current state is.
https://bugzilla.redhat.com/show_bug.cgi?id=2124835
--- Comment #3 from fujiwara tfujiwar@redhat.com --- CUrrently an XKB source is always configured using the current locale by default in GNOME. I also prefer the default input mode is ASCII but it's not agreed by Jens Petersen. Only an input method source is configured for Japanese in MS-IME but the two sources are setup for Chinese in MS-IME too. We may consider the configuration by language.
https://bugzilla.redhat.com/show_bug.cgi?id=2124835
--- Comment #4 from Akira TAGOH tagoh@redhat.com --- You lost me. How does the XKB source affect *single* input mode? I understand that XKB source affects the keymap in the engine though, they affect it regardless of "default" and "current". Even now, the behavior on typing is changed once changing XKB source though.
If there are any reasons, can you elaborate on how hard ibus-anthy merge both "default" and "current" input modes into single input mode?
https://bugzilla.redhat.com/show_bug.cgi?id=2124835
--- Comment #5 from fujiwara tfujiwar@redhat.com --- I mean if the default input mode is Hragana, I expect ibus restart bring back to Higarana mode. The default mode is different from mozc.
https://bugzilla.redhat.com/show_bug.cgi?id=2124835
--- Comment #6 from Akira TAGOH tagoh@redhat.com --- My suggestion here is to keep "current" input mode only. major Japanese Input Method doesn't have such "default" input mode. that makes complicated. why do you want to maintain "default" and "current" separately?
https://bugzilla.redhat.com/show_bug.cgi?id=2124835
--- Comment #7 from fujiwara tfujiwar@redhat.com --- I think MS-IME's default mode is direct and there is no daemon restart. I don't think restarting the daemon to reset the input mode makes complicated and also restarting daemon is a maintenance way so I wish to reset the all the state and you don't have to run the command so many times. You just could change the input mode after ibus restart, didn't you?
https://bugzilla.redhat.com/show_bug.cgi?id=2124835
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed| |2022-09-27 05:41:54
--- Comment #8 from Akira TAGOH tagoh@redhat.com ---
so I wish to reset the all the state
Gotcha.
I'm still wondering why ibus-anthy wants to have initial input mode in setup dialog though, that may be another story. let's close this. thanks for explanation.
i18n-bugs@lists.fedoraproject.org