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
IME modes.

I cannot reproduce your problem.

I can type multi-byte @ with Shift + 2
Did you have the US layout?

# cat /etc/sysconfig/keyboard 
KEYBOARDTYPE="pc"
KEYTABLE="us"
LAYOUT="us"
MODEL="pc105+inet"
OPTIONS=""
VARIANT=""

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.

    <schema>
      <key>/schemas/desktop/ibus/general/use_system_keyboard_layout</key>
      <applyto>/desktop/ibus/general/use_system_keyboard_layout</applyto>
      <default>false</default>
    </schema>

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:
/usr/share/ibus/component/anthy.xml

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. :)