Bug 509518

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