What version of the product are you using? On what operating system? OS (Linux distributions, UNIX or ...): Archlinux Architecture (i386, x86_64): x86_64 IBus version: 1.5.0 Input method name and version: any Python version: 3.3.0/2.7.3 dbus version: 1.6.8 dbus-python version: 1.1.1 gtk version (if bug is about gtk applications): 2/3 qt version (if bug is about qt applications):

What steps will reproduce the problem? 0. Make sure ibus is running 1. type "setxkbmap fr bepo" in a terminal, that will change your keyboard layout to a French like one 2. You can type in French correctly 3. Ctrl-Space to change the input method to pinyin for example 4. your keyboard layout is now using qwerty 5. switch back…

Ibus doesn't take into account the "use system layout" option at all.

Problems: There is no "French dvorak bepo" keyboard in the ibus input methods, and the "use system layout" doesn't do anything.

Thanks for reporting. IBus 1.5 has architectural difference from IBus 1.4.

In 1.4, we only provide input method engines that either respect system layout or not.

In 1.5, we provide both input method engines and XKB engines. XKB engines provide different layouts and the input methods' layouts are determined by themselves only. I guess IBus 1.5 overwrite layout setting all the time and the option is not respected. The solution, I guess, should be that we provide a per input method engine layout setting.

Fcitx precisely handles it this way.

Fcitx precisely handles it this way.

I definitely know such fact. If you have trouble switching to Fcitx, please use Fcitx's supporting channel or send me private mail. If you still want IBus to improve, the above message doesn't help much since we won't seriously check Fcitx's code base?

I just meant another software does it the way you explained it, and I thought it would just confirm your idea is great.

If you want to know, I'm using Fcitx while Ibus is not usable for me any more.

But if I took some time to open a bug request, it's because I want Ibus to get better, and to continue to use it!

I'm very sorry if I offended you in any way.

Yes, we keep the "use system layout" option in ibus 1.5 at the moment for this purpose but it's not implemented and I'm not sure if it's really needed because if you add French layout using 'ibus-setup' command, you will be able to set fr layout. And currently I think it's good if ibus-pinyin also could provide the layout customization.

Probably we can implement the feature of "use system layout" later.

The only thing, is that I cannot add the right French keyboard in Ibus-setup. I can easily use my "dvorak bepo" French keyboard anywhere (since it's built in Xorg) by using the following command line: setxkbmap fr bepo

However, Ibus doesn't offer me the choice of that keyboard for French.

What's the difference between "French (Dvorak)" in IBus and "dvorak bepo"?

French (Dvorak) correspond to the following command line: setxkbmap fr dvorak Here is how it looks like on a keyboard: https://fr.wikipedia.org/wiki/Fichier:KB_French_Dvorak_text.svg

French (bepo, dvorak) correspond to the following command line: setxkbmap fr bepo Here is how it looks like on a keyboard: https://fr.wikipedia.org/wiki/Fichier:KB_French_Dvorak_b%C3%A9po_simplifi%C3%A9.svg

Thank you for your information.

takao.fujiwara1, do you know why something available from XKB (setxkbmap fr bepo) is missing from IBus? This seems to be a more fundamental problem.

My guess is that we provide all the available layouts but have no way to configure their variants or other details?

If you add the following lines in /usr/share/ibus/component/simple.xml and restart ibus, ibus-setup will show "French (Bepo, ergonomic, Dvorak way)":

            <engine>
                    <name>xkb:fr:bepo:fra</name>
                    <language>fra</language>
                    <license>GPL</license>
                    <author>Peng Huang &lt;shawn.p.huang@gmail.com&gt;</author>
                    <layout>fr</layout>
                    <layout_variant>bepo</layout_variant>
                    <longname>French (Bepo, ergonomic, Dvorak way)</longname>
                    <description>French (Bepo, ergonomic, Dvorak way)</description>
                    <icon>ibus-keyboard</icon>
                    <rank>1</rank>
            </engine>

Currently ibus upstream shows the limited keymaps in ibus-setup and we can add new one with request. The long plan is to provide the customize UI.

So your request is to provide fr(bepo) engine but not to customize the layout in ibus-pinyin.

This is really nice, and it allows me to write in French again with ibus! So, thank you very much.

However, switching to pinyin, for example, switch my keyboard to qwerty… that's not really what I want though.

The customize UI you spoke about will let us choose a keyboard layout for each input method?

Hello,

I am unsure to understand this ticket. Is there a problem when your system layout is bépo, or is it about being able to write in bépo while your system layout is different?

I would personally like to be able to do the later (I configured my system to qwerty, but would like to switch back and forth to bépo at will). So I wanted to try out the engine as explained by Takao. But I can't find a /usr/share/ibus/component/simple.xml on my system. Is it a file only on newer versions of Ibus (here ibus 1.4.1)? Or even only in the dev repository? Thanks.

Hello Jehan,

Just to make it clear: My system layout: French dvorak bepo (for both TTY and Xorg)

Now ibus handles the switch between every input method, even French. Changing simple.xml allows me to have a French bépo layout when I'm not using a Chinese input method. (does not work since 1.5 version).

When using any input method, like pinyin, my keyboard layout is switched to qwerty. Before ibus version 1.5, the switch [use system layout] worked, and let me type Chinese with pinyin with my bepo layout. However, this does not work any more.

Probably the ibus fix will be later after ibus-dconf fixes correctly. Originally I thought to use the value the use-system-layout but the default was TRUE in ibus 1.4 but probably now it should be FALSE to use the ibus xkb engines and some users could costomize it. And the probably the new dconf key would be better but currently ibus-dconf is quite buggy in the name conversion. It would be good to wait for new gsettings for new values.

At the moment, you could modify tag and add tag in /usr/share/ibus/component/pinyin.xml by manual and restart ibus-daemon.

• us
• fr
• bepo

I didn't get why the title was changed. Original issue was about ibus not respecting system layout(s) thus the submitter was pushed to set ibus to provide fr(bepo) as well...

But I would expect that it would be possible to switch my two system layouts [us,cz(qwerty)] using alt+shift back and forth. BTW, I recognize second layout via Scroll Lock LED... I rarely use ctrl+space to activate ibus+anthy for japanese letters.

What I read here looks like ibus will add third layout and I will have to iterate through jp to get back from cz to us... or am I wrong?

Takao, 答えて下さい ;-)

But I would expect that it would be possible to switch my two system layouts [us,cz(qwerty)]

The group XKB layout won't be available in ibus because ibus separates the layout by engine while you could add it in /usr/share/ibus/component/simple.xml directly.

us,cz ,qwerty

ibus does not change the XKB options so if you set the options in the session they will be inherited by each engine but the options about switching keymaps are not used by ibus.

The engine specific shortcut keys are not implemented yet.

I have been using a ~/.Xmodmap file to remap my capslock key to control. Starting a month or two ago, that option gets reset every time I activate ibus. Is there a recommended way of remapping capslock with the current version of ibus? There isn't a pre-made system layout for that. I'm using archlinux and no desktop environment.

Thanks! Eric

17

This is the exact same problem I am having.

Also, when I switch to ibus-anthy, my Japanese keyboard gets set to a Japanese layout. But I want to type in Japanese with a US layout.

If you look in the Anthy preferences under ibus (the button's in the place where you can change the order of the input methods), you can adjust the layout used with Anthy. I chose the 'system layout' (not to be confused with the global 'system layout' in ibus) and got Dvorak.

Also, setting XKB options via setxkbmap solved all of my issues regarding caps lock and compose.

I used to have this setup before with ibus-1.4:

1. xkb configuration in xorg.conf: Option "XkbLayout" "us+typo,ru:2+typo"
   Option "XkbOptions" "grp:caps_toggle,grp_led:scroll,terminate:ctrl_alt_bksp,lv3: ralt_switch"

2. Toggle key in ibus was Control-Space with Japanese Anthy method. So I could switch to Japanese whether I had us+typo or ru+typo at the moment and then switch back.

So is a similar setup impossible anymore with ibus 1.5?

1. xkb configuration in xorg.conf: Option "XkbLayout" "us+typo,ru:2+typo"
   Option "XkbOptions" "grp:caps_toggle,grp_led:scroll,terminate:ctrl_alt_bksp,lv3: ralt_switch"

If ibus 1.5 takes the session XKB options. And you need to enable 'us' and 'ru' ibus engines with ibus-setup and then you can switch 'us', 'ru' and 'anthy'. The 'anthy' layout is 'jp' by default but you can change it to 'default' with ibus-setup-anthy, which does not change the current layout.

If ibus 1.5 takes the session XKB options.

typo: ibus 1.5 takes the session XKB options.

takao.fujiwara, but the setup you offered does not allow me to: 1. Switch layouts with Caps Lock. ibus-setup does not allow to set even Ctrl-Shift or Alt-Shift as "next layout" shortcut. The default Ctrl-Space is a very unusual shortcut for me. 2. Add the additional layout "typo" to easily enter symbols like ® © € ° — £ ¥ using Right Alt key. 3. Keep "grp_led:scroll". It's not very important, but I'd like to keep it as well.

Also, I sometimes use Compose Key in combination with typo, forgot to mention that.

1. Switch layouts with Caps Lock. ibus-setup does not allow to set even Ctrl-Shift or Alt-Shift as "next layout" shortcut.

I can set "Shift_L" and "Shift_L" with ibus-setup and switch engines. You need to enable Control or Alt button and type "Shift_L" manually on ibus-setup.

2. Add the additional layout "typo" to easily enter symbols like ® © € ° — £ ¥ using Right Alt key.

If you choose "English(US, internaltional with dead keys)" ibus engine, you can type those chars with right Alt.

3. Keep "grp_led:scroll". It's not very important, but I'd like to keep it as well.

As I noted above, ibus does not touch the XKB options so if you configure the system XKB options, ibus switches layout and variant keeping with your XKB options.

Also, I sometimes use Compose Key in combination with typo, forgot to mention that.

Same. You can configure the system XKB options.

You need to enable Control or Alt button and type "Shift_L" manually on ibus-setup.

Ok, but what about Caps Lock, is it not implemented?

If you choose "English(US, internaltional with dead keys)" ibus engine, you can type those chars with right Alt.

This is interesting, some signs are missing (m-dash, pound, minutes, seconds), but these can be worked around with Compose key. And I can't input quotes (' and ") in this layout the way I do it in "English (US)". In deadkeys layout the quotes key is used to for a different purpose. This is more serious.

As I noted above, ibus does not touch the XKB options No, I lose my XKB options immediately when ibus is launched. That is, I can't switch layouts the way I did before ibus started (with Caps Lock). After that layouts can only be switched to what is configured in ibus using ibus shortcut. If I stop ibus, there's no more any way to switch. I have the checkbox "Use the system keyboard latout" checked.

Ok, but what about Caps Lock, is it not implemented?

I can switch engines by Caps_Lock. If you want to remove the lock state, it's not an ibus issue and probably it's good to swap Caps_Lock and Control_L.

some signs are missing (m-dash, pound, minutes, seconds)

It's good to describe the unicode. I'm thinking to provide the compose customization in ibus.

And I can't input quotes (' and ") in this layout the way

I don't understand this. The ASCII chars ' and " are assigned in the us(intl) layout.

No, I lose my XKB options immediately when ibus is launched.

Your configuration would be wrong. ibus runs setxkbmap for the XKB keymaps and setxkbmap does not change the current XKB options. You can check the behavior without ibus.

% setxkbmap -query % setxkbmap -layout us % setxkbmap -query

I can switch engines by Caps_Lock I tried this, but with a single key I can only switch between 2 layouts (back and forth). In order to switch between 3 or 4 layouts I need to add a modifier key (like Ctrl). Then it's possible to hold Ctrl and press Caps Lock multiple times.

It's good to describe the unicode. I'm thinking to provide the compose customization in ibus. Unicode for those are U+2014 U+00A3 U+00B0 U+00D7 U+00AB U+00BB U+2026

I don't understand this. The ASCII chars ' and " are assigned in the us(intl) layout. Maybe it's another key in us(intl), not the most right key in the middle row with letters.

Your configuration would be wrong. ibus runs setxkbmap for the XKB keymaps and setxkbmap does not change the current XKB options.

I see, so ibus runs setxkbmap and sets layout list to only 1 layout at a time instead of comma-separated list?

There's another problem with that. If I switch to Russian layout (with ibus or "setxkbmap -layout ru"), I can't use shortcuts with English letters anymore (Ctrl-C, Ctrl-W, Ctrl-X etc.). But if run "setxkbmap -layout us,ru", it's possible to use shortcuts on both "us" and "ru" layouts.

I tried this, but with a single key I can only switch between 2 layouts (back and forth).

Yes, no modifier key switches 2 layouts and you need modifier keys to switch more than 3 layouts.

Unicode for those are U+2014 U+00A3 U+00B0 U+00D7 U+00AB U+00BB U+2026

OK, I confirmed U+00A3 U+00B0 U+00D7 U+00AB U+00BB can be typed with us(intl) keymap. I think ibus needs to provide the layout customization. You could use fr(bepo) for U+2014 U+2026 or Ctrl + Shift + u + 2014 or ibus-input-pad at the moment.

There's another problem with that. If I switch to Russian layout (with ibus or "setxkbmap -layout ru"), I can't use shortcuts with English letters anymore (Ctrl-C, Ctrl-W, Ctrl-X etc.).

You need to switch us layout to type English letters. The switching XKB option key would be replaced with ibus switching key.

takao.fujiwara1, maybe you can add a feature for ibus to switch between XKB "default" layout? In my case I could use ibus to switch between 2 of them: "us+typo,ru:2+typo" <===> "ja" In other words, the same setup I used with ibus 1.4. It would resolve a lot of inconveniences.

I meant "switch between XKB default and other layouts".

maybe you can add a feature for ibus to switch between XKB "default" layout?

Probably I think that approach does not work because of no way to get the current layout. When you set a customized keymap, after you change a layout, e.g. 'jp', there is no way to bring back the orignal keymap.

% setxkbmap -layout foo % setxkbmap -layout jp

BTW, if you modify /usr/share/ibus/component/simple.xml by manual to add a layout and restart ibus-daemon, the layout could be shown in ibus-setup:

            <engine>
                    <name>xkb:us,ru::eng</name>
                    <language>eng</language>
                    <license>GPL</license>
                    <author>Peng Huang &lt;shawn.p.huang@gmail.com&gt;</author>
                    <layout>us,ru</layout>
                    <longname>English (US) + Russian</longname>
                    <description>English (US) + Russian</description>
                    <icon>ibus-keyboard</icon>
                    <rank>0</rank>
            </engine>

But I don't think the group layout is not needed because you can switch two ibus engines. Currently I'm thinking to provide the customized compose keys only.

typo:

But I don't think the group layout is not needed But I don't think the group layout is needed

To fix the configuration I've been using for years before I had to add:

    <engine>
        <name>xkb:ru:us-dvorak:rus</name>
        <language>rus</language>
        <license>GPL</license>
        <author>Peng Huang &lt;shawn.p.huang@gmail.com&gt;</author>
        <layout>us,ru</layout>
        <layout_variant>dvorak,</layout_variant>
        <longname>English (dvorak) + Russian</longname>
        <description>English (dvorak) + Russian</description>
                    <icon>ibus-keyboard</icon>
        <rank>99</rank>
    </engine>

The idea of adding two separate english and russian layouts doesn't work, because, apart from being accustomed to the old separate shortcuts for en<->ru and en,ru<->jp switches, as noted above using Russian alone breaks shortcuts like Ctrl-C/Ctrl-V etc. Having to switch layouts just to use them is unreasonable.

as noted above using Russian alone breaks shortcuts like Ctrl-C/Ctrl-V etc.

If you switch the layout to 'ru' in en,ru, I think you also cannot use Ctrl-C/Ctrl-V until you switch the layout to 'en' in en,ru.

No, there is some magic code somewhere in the hotkey handling that finds and uses the english layout in the group, whether it is currently selected for normal text input or not.

And actually the simple "Russian" choice in ibus automatically includes the us layout too, probably for this very reason. The problem for me is that it is "ru,us" instead of "us,ru", and not dvorak either.

No, there is some magic code somewhere in the hotkey handling that finds and uses the english layout in the group, whether it is currently selected for normal text input or not.

I don't understand your problem.

As mentioned above in pure XKB environment hotkeys with English letters work on ALL layouts in the group. That is, if you are currently typing "ru" text having "us, ru" group activated and wish to use copy a text block with Ctrl-C, you don't have to switch to "us" layout in the group. With ibus you have to switch, type Ctrl-C, then switch back.

I got your problem. I'm interested in that mono layout 'ru' and the layout 'ru' in group layout 'en,ru' are different. Probably I think it's good to provide an xkb engine for the default layout but need to think how to implement it. It's good for you to file a new bug since this bug is the use-system-layout property and it will effect input method engines instead of xkb engines.

I filed a new bug here: https://code.google.com/p/ibus/issues/detail?id=1598

Issue 1602 has been merged into this issue.

Finally use-system-keyboard-layout property was applied for both input method and xkb engine. And changed the default value from true to false not to wait for gsettingslist.

https://github.com/ibus/ibus/commit/4b2f6a477019b50375aba2e5f9c43e618b6905ad

I have had a same issue with ibus-mozc, and this fix seems to be not enough. I'm using US keyboard layout, but when default input method is Mozc and 'use system layout' on latest ibus is enabled, my keyboard layout is fixed to JP.

'use system layout' setting seems to be loaded after input method engine is selected. The behavior I guess is: when selecting input method engine, the engine set its respective keyboard layout, then 'use system layout' setting is loaded, and keyboard layout will be not modified any more.

I moved the line set_use_system_keyboard_layout(null); onto just above the line update_engines(m_config.get_value("general", "preload_engines"), , that fixed the problem, though I wasn't tested well.

'use system layout' setting seems to be loaded after input method engine is selected.

Thanks for the evaluation. Fixed that issue too: https://github.com/ibus/ibus/commit/5fa461889939a91fecff89a67630076b8cb987b2

I'd just like to add my own experience here:

I'm a Fedora 20 user, which packages ibus 1.5.4. I use a German keyboard layout in the nodeadkeys variant, configured via KDE's xkb frontend.

A few days ago I installed ibus for the first time to gain the ability to type Hangul. Sadly, I wasn't able to retain the ability to type German with disabled dead keys with ibus running. The nodeadkeys variant isn't listed among the German layouts in the ibus GTK3 frontend, and the "Use system keyboard layout" checkbox had no effect.

Then I found this ticket, and added /usr/share/ibus/component/simple.xml to add a nodeadkeys variant and restarted ibus. Surprisingly, it even added the input method automatically to the list. For good measure I wiped the list anyway and added my newly-created "German (Eliminate dead keys)" and Hangul fresh, and now everything works just like I want it to.

I don't understand the system well enough to determine whether this means nodeadkeys should be added in the upstream simple.xml, or if "Use system keyboard layout" should work but is actually broken.

s/and added/and edited/, sorry for the typo.

I don't understand the system well enough to determine whether this means nodeadkeys should be added in the upstream simple.xml, or if "Use system keyboard layout" should work but is actually broken.

I think "Use system keyboard layout" should work. After enable it, you need to log in the session again or you can set the XKB keymap by manual:

% ibus exit % setxkbmap -query % setxkbmap -layout de -variant nodeadkeys % ibus-daemon --xim --verbose &

I'm interested in the purpose of nodeadkeys.

Thanks for your reply :).

'nodeadkeys' means I can type various things with just one keypress instead of two, e.g. '^'. I use some keyboard shortcuts which rely on this to be true, and for others a more common usecase is probably convenient typing of emoticons.

Note that the German keyboard layout has dedicated keys for the vowels with diacritics (aka umlauts) German itself uses, and few Germans regularly type words which require the use of accents, so dead keys are simply less useful than no dead keys for many typical German typing habits. Using the nodeadkeys variant is therefore very common.

Regarding "Use system keyboard layout", I didn't try to re-login after toggling it. But I assume that KDE actually runs setxkbmap before ibus has a chance to start, so the above sequence may not be easily achievable for KDE users, unless they disable KDE's xkb frontend and use other means to run setxkbmap after ibus startup.

Addendum: It's not relevant to me, but it might be worth pointing out that nodeadkeys is the default behavior in a German Windows installation. I.e. folks who switch from Windows are used to the keyboard behaving in this way, further increasing the popularity of this layout variant.

Regarding "Use system keyboard layout", I didn't try to re-login after toggling it. But I assume that KDE actually runs setxkbmap before ibus has a chance to start, so the above sequence may not be easily achievable for KDE users, unless they disable KDE's xkb frontend and use other means to run setxkbmap after ibus startup.

It's an expected result. If the desktop provides the tool of keymaps, I rather suggest to use it and set de(nodeadkeys) correctly instead of the system layout. Uncheck "Use system keyboard layout" means ibus does not change the current keymap so you need to check the current keymap before you run/restart ibus.

Well, that didn't work either though, as mentioned. Once I started using ibus, and added German and Hangul to the list (so I can cycle between them), the German layout was the with-deadkeys variant, until I edited the xml. Perhaps I'm doing it wrong and instead of adding German to the list in ibus I should be using some sort of hotkey to just enable/disable ibus to switch between Hangul and German?

(Sorry if this is starting to be more of a support talk now ... but then again it might help others googling for this, it's how I found this ticket too.)

Well, that didn't work either though, as mentioned.

It should work and you don't have to modify xml file. File a new issue if you still have an error in settings since your issue is not this feature.

I’m reading this bug report here and am asking myself what an “xkb engine” is.

“Engine” sounds like it’s doing something. I’m thinking “xkb engine” means “sets some specific xkb settings like setxkbmap would do and leaves the real IME(s) off.”

This raises the question: how to configure xkb layouts when I use a real IM engine? If I’m supposed to do this outside of ibus, why does ibus fiddle with xkb at all?

Yes, the ibus xkb engine runs setxkbmap internally.

how to configure xkb layouts when I use a real IM engine?

Each engine has the keymap setting.