Description of problem:
anthy should not override kbd layout to jp (by default at least)
since it is not necessary.
I think we only need kbd layout override for Chewing, some m17n maps
and a few others maybe, not anthy currently anyway.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. use anthy with US kbd
2. Alt-` and press Shift-2
Is it? isn't it necessary for kana input so far? it won't be needed after we move to the layout switch on xkb or xinput perhaps.
(In reply to comment #0)
> I think we only need kbd layout override for Chewing, some m17n maps
> and a few others maybe, not anthy currently anyway.
Tagoh-san is right - it is needed for Kana input mode on non-US kbds,
but that's a corner case - so we should still default to system
layout for Anthy until we can fine-grain control to individual
I cannot reproduce your problem.
I can type multi-byte @ with Shift + 2
Did you have the US layout?
# cat /etc/sysconfig/keyboard
Hmm.., after I upgrade ibus 1.1 to 1.2, I could reproduce this bug.
So I think this is an ibus bug instead of ibus-anthy one.
I found another problem.
When I change keycode, ibus still sends the original keyval.
E.g. I change Menu to Henkan.
% xmodmap -e "keycode 135 = Henkan".
1. Type Ctrl + Space.
2. Type Menu key.
Then 'ibus/engine.py:' EngineProxy::ProcessKeyEvent() receives keyval = 0xff67.
I expected to receive 0xff23.
This is also reproduced in 1.2 but not 1.1.
After I run ibus-setup and enable [Use system keyboard layout setting] in [Advanced] tag, I won't reproduce this bug.
Personally I feel the default enable setting might be preferred.
Transferring the decision.
So you mean you feel it is notabug?
> So you mean you feel it is notabug?
I guess it depends on whether we enable the default value or disable it.
ibus/data/ibus.schemas.in includes the following gconf value.
Do you prefer the disabled value by default?
Does it effect when the check box button [Use system keyboard layout setting] is enabled and European people change the keyboard layout with gnome-keyboard-applet?
Created attachment 357732 [details]
Patch for ibus/bus/Makefile.am, ibus/bus/engineproxy.c, ibus/bus/main.c, ibus/configure.ac, ibus.spec
Created the tentative patch to fix this problem.
/usr/share/ibus/component/anthy.xml has the hardcoded layout "jp".
Then if system layout is not used, "jp" is used.
I think XKB could resolve this bug.
Since gnome-keyboard-applet uses libxklavier, my suggestion is to implement libxklavier and override the hardcoded "jp".
I think it would works with GDM.
I think this patch will effect all engines, and it will also make ibus-daemon depend on X library. I think we should avoid using X libraries in the ibus-daemon.
Talking off line, it seems some engines require "us" layout against the physical keyboard.
Transferring to ibus. Currently the maintainer works to be able to customize the engine layout:
Probably I think it's better to enable system layout or disable one by default per engine.
I thought the system layout would meant /etc/sysconfig/keyboard but actually it indicates XKB layout likes user layout so it might be better to change the UI string likes "Use the current keyboard layout setting".
Created attachment 360169 [details]
Patch for ibus.schemas.in
This is a workaround to change the schemas value for ja locale only if you require en layout for other engines.
If you change the default value "false" to a module specific value, it can be extracted into .po file.
I think it is better to use System keyboard layout setting by default. It has been fixed in upstream. I will build it for rawhide soon.
Fixed in ibus-1_2_0_20090915-1_fc12
Thanks - looks good now. :)