Open yodalee opened 6 years ago
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
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
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
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
[deleted comment]
> 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:
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
> 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
Attachments:
Original comment by yukawa@google.com
on 27 Oct 2013 at 1:47
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
(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
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
> 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
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
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
Issue 238 has been merged into this issue.
Original comment by yukawa@google.com
on 12 Jul 2014 at 3:47
Issue 238 has been merged into this issue.
Original comment by yukawa@google.com
on 12 Jul 2014 at 3:47
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
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
Original comment by yukawa@google.com
on 12 Jul 2014 at 6:23
Original comment by yukawa@google.com
on 12 Jul 2014 at 9:13
Original comment by yukawa@google.com
on 21 Apr 2015 at 6:15
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?
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.
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.
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.
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.
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)
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.
Original issue reported on code.google.com by
f.takeya...@gmail.com
on 24 Oct 2013 at 3:51