Description of problem: When a keyboard layout is changed with gnome-settings-daemon, ~/.Xmodmap is automatically re-applied through libgnomekbd. cf. http://blogs.gnome.org/sudaltsov/2010/10/13/xmodmap-and-gnome/ http://git.gnome.org/browse/libgnomekbd/tree/libgnomekbd/gkbd-keyboard-config.c#n582 However, with ibus-xkb, that file is ignored and the previous Xmodmap setting is cleared each time when I switch between XKB engines. Version-Release number of selected component (if applicable): ibus-1.4.0-6.fc16.x86_64 How reproducible: always Steps to Reproduce: (with the default Japanese installation of F16 RC2) 1. put the following content in ~/.Xmodmap keycode 49 = Escape 2. xmodmap ~/.Xmodmap 3. run xev and type Zenkaku_Hankaku key 4. select Thai XKB engine from the IME menu, then back to Japanese XKB engine 5. run xev and type Zenkaku_Hankaku key Actual results: xev reports "keycode 49 (keysym 0xff1b, Escape)" on step 3, and "keycode 49 (keysym 0xff2a, Zenkaku_Hankaku)" on step 5. Expected results: xev should report "keycode 49 (keysym 0xff1b, Escape)" on both step 3 and 5. Additional info: This feature would be important on Japanese desktop, since quite a few people map Zenkaku_Hankaku to Escape.
Thanks for that pointer of the codes. Probably I'd update ibus.xkblayout.set_layout for Fedora for the short term. Unfortunately I think this needs to be called after set_layout is called. I'm also thinking to port ibus.xkblayout to ibus-xkb for Fedora 17: https://github.com/fujiwarat/ibus-xkb Then ibus-xkb also needs to have the similar implementation. BTW, we also need to implement a config file similar with ~/.XCompose . http://desktopi18n.wordpress.com/2011/09/30/ibus-xim-compose-key/
Created attachment 532262 [details] Patch for xkblayout.py.in The attachment is the tentative patch. Now setting xkb & xmodmap uses the async function. I also will update ibus-gnome3.
ibus and ibus-gjs are updated: https://github.com/fujiwarat/ibus-gjs/commit/b1e2501cd62707c07cdf18dde6a83a59d1ab8ba4 Now I added .xmodmaprc and .Xmodmaprc files too. However probably I don't recommend to use .xmodmap*. E.g. if .xmodmap replaces Ctrl and Caps_Lock and you switch engines by Control + Space, you will see an error from xmodmap command since you're pressing Control key. So you need to release the Control key soon after you type Control + Space. We could use XKB option ctrl:swapcaps instead.
(In reply to comment #3) > ibus and ibus-gjs are updated: > https://github.com/fujiwarat/ibus-gjs/commit/b1e2501cd62707c07cdf18dde6a83a59d1ab8ba4 Thanks for the quick update. It basically works. However, if I don't have the gconf key /desktop/ibus/general/use-xmodmap, loading the extension fails with: TypeError: this._config.get_value('general', 'use-xmodmap', GLib.Variant.new_boolean(true)) is null It seems that this is because get_value()'s 3rd arg is only available in the Python binding and not in GI. I added the following to ibusPanel.js to work around this: // patch IBus.Config.get_value to accept defval argument IBus.Config.prototype._get_value = IBus.Config.prototype.get_value; IBus.Config.prototype.get_value = function(section, name, defval) { let value = this._get_value (section, name); if (value == null) return defval; return value; }; Also, is it intentional that "-" is used instead of "_" in the gconf key? > However probably I don't recommend to use .xmodmap*. E.g. if .xmodmap replaces > Ctrl and Caps_Lock and you switch engines by Control + Space, you will see an > error from xmodmap command since you're pressing Control key. Fully agreed. FWIW, for the case described in the report (i.e. Zenkaku_Hankaku as Escape), I requested a new XKB option: https://bugs.freedesktop.org/show_bug.cgi?id=42734
(In reply to comment #4) > (In reply to comment #3) > > ibus and ibus-gjs are updated: > > https://github.com/fujiwarat/ibus-gjs/commit/b1e2501cd62707c07cdf18dde6a83a59d1ab8ba4 > > Thanks for the quick update. It basically works. However, if I don't have the > gconf key /desktop/ibus/general/use-xmodmap, loading the extension fails with: > Ah, I mean I also integrated the ibus part of attachment 532262 [details] in my ibus fedora branch. > Fully agreed. FWIW, for the case described in the report (i.e. Zenkaku_Hankaku > as Escape), I requested a new XKB option: > https://bugs.freedesktop.org/show_bug.cgi?id=42734 Interested :).
ibus-1.4.0-11.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/ibus-1.4.0-11.fc16
ibus-1.4.0-11.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ibus-1.4.0-11.fc15
Package ibus-1.4.0-11.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ibus-1.4.0-11.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16111/ibus-1.4.0-11.fc16 then log in and leave karma (feedback).
ibus-1.4.0-13.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/ibus-1.4.0-13.fc16
ibus-1.4.0-11.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
ibus-1.4.0-11.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.