Created attachment 530447 [details] screenshot of ibus-gnome3 menu Description of problem: When I have the following xkb settings, ibus-gnome3 shows the default layout as "jp Japanese (Default Layout (,euro,,))". Maybe there are some option names should be shown instead of empty strings? Screenshot attached. xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+jp+us(euro):2+us:3+fr:4+inet(evdev)+group(shift_caps_toggle)+ctrl(nocaps)" }; xkb_geometry { include "pc(pc104)" }; }; Version-Release number of selected component (if applicable): ibus-1.4.0-5.fc16.x86_64 ibus-gnome3-1.4.0-5.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: "jp Japanese (Default Layout (,euro,,))" is shown in the menu Expected results: "jp Japanese (Default Layout (euro))" or something more informative is shown in the menu Additional info:
XKB group keymaps can be shown up as far as four and ibus's first keymap engine has the combined keymap and the 2nd to 4th keymap engines has one mono keymap. E.g. if you configure the group layout as 'us(euro),us,jp', the first keymap is 'us(euro),us,jp' and the second is 'us' and the third is 'jp'. I showed variants in the menu GUI to distinguish the combined keymap and the mono keymap. Probably I guess 'euro,none,none' is too wide in the menu GUI. Probably I think the combined keymap is needed so that XKB option keys work with/without ibus. Now I'm thinking if all the four keymaps need to be combined keymaps but I think it means ibus needs to track the XKB option key to switch ibus IMEs. Or all ibus engines are mono keymaps? but it means XKB option keys would not work. I don't think to show XKB options on menu GUI due to the limited menu width. I agree to think the better label for the combined keymap. Hmm.. E.g. the first variant and number but 'English (euro x 3)' might mislead all keymaps have euro variant. Maybe 'English (euro, ∅, ∅)' ?
(In reply to comment #1) > XKB group keymaps can be shown up as far as four and ibus's first keymap engine > has the combined keymap and the 2nd to 4th keymap engines has one mono keymap. > E.g. if you configure the group layout as 'us(euro),us,jp', the first keymap is > 'us(euro),us,jp' and the second is 'us' and the third is 'jp'. Thanks for the explanation. I didn't even notice the first keymap is combined. > Probably I think the combined keymap is needed so that XKB option keys work > with/without ibus. Maybe I don't understand the situation you are thinking of, do you mean, say, even if ctrl:nocaps/ctrl:swapcaps is set for the second keymap, "Caps_Lock+Space" wouldn't work as "Control+Space"? > I don't think to show XKB options on menu GUI due to the limited menu width. > I agree to think the better label for the combined keymap. Hmm.. > E.g. the first variant and number but 'English (euro x 3)' might mislead all > keymaps have euro variant. > Maybe 'English (euro, ∅, ∅)' ? How about showing it more explicitly as combined, like "Keyboard (en(euro), en, ja)" ?
(In reply to comment #2) > > Probably I think the combined keymap is needed so that XKB option keys work > > with/without ibus. > > Maybe I don't understand the situation you are thinking of, do you mean, say, > even if ctrl:nocaps/ctrl:swapcaps is set for the second keymap, > "Caps_Lock+Space" wouldn't work as "Control+Space"? Ah, I mean XKB toggle keys for example. If g-c-c sets grp:rwin_switch, I think users would expect to switch the XKB keymaps with Win-key with/without ibus. If the first ibus keymap engine is not the combined keymap, I would think ibus need to track the Win-key event with libxklavior. So I guess the combined keymap might be fine. > > I don't think to show XKB options on menu GUI due to the limited menu width. > > I agree to think the better label for the combined keymap. Hmm.. > > E.g. the first variant and number but 'English (euro x 3)' might mislead all > > keymaps have euro variant. > > Maybe 'English (euro, ∅, ∅)' ? > > How about showing it more explicitly as combined, like "Keyboard (en(euro), en, > ja)" ? OK, it might be better than my idea if the width is no problem. I will test your idea. Thanks.
(In reply to comment #3) > If g-c-c sets grp:rwin_switch, I think users would expect to switch the XKB > keymaps with Win-key with/without ibus. If the first ibus keymap engine is not > the combined keymap, I would think ibus need to track the Win-key event with > libxklavior. > So I guess the combined keymap might be fine. Got it, thanks. But then, if this is the only case, isn't it feasible to track group change event (instead of Win-key event) with libxklavior and update the menu labels so that all of them look like mono keymaps? I mean, the first keymap is still combined but the menu label looks like mono.
(In reply to comment #4) > Got it, thanks. But then, if this is the only case, isn't it feasible to track > group change event (instead of Win-key event) with libxklavior and update the > menu labels so that all of them look like mono keymaps? I mean, the first > keymap is still combined but the menu label looks like mono. I agree with your point. Now I'm thinking all ibus keymap engines need to be combined keymaps and similar behavior with gnome-settings-daemon keyboard GUI. Then I would think ibus needs to contact libgnomekbd to get the keyboard status. Also thinking about #2 in the upstream bug comment #51: https://bugzilla.gnome.org/show_bug.cgi?id=641531#c51 Probably I think ibus needs to have the different UI between GNOME and non-GNOME due to libgnomekbd. Probably I think upstream wants to use libgnomekbd simply for gnome3. For GNOME: libgnomekbd is used and ibus-xkb won't be used. ibus keymap engine is combined keymap and can be configured by gnome-control-center only. For non-GNOME: ibus-xkb is used. ibus keymap engine is mono keymap and can be configured by ibus-setup (will be ibus-setup-xkb). Originally I thougut the number of XKB keymaps is limited by four but technically ibus keymap engine is unlimited. And I implemented the first ibus keymap engine only is combined keymap. However probably there would be several problems and complicated. I'm also thinking probably using libgnomekbd does not need bridge-hotkey feature. To detect desktops, I'd think DESKTOP_SESSION by default at the moment. Using X11 Atom would be complicated, I guess.
ibus-1.4.99.20120317-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/ibus-1.4.99.20120317-1.fc17
Package ibus-1.4.99.20120317-1.fc17: * should fix your issue, * was pushed to the Fedora 17 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.99.20120317-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4134/ibus-1.4.99.20120317-1.fc17 then log in and leave karma (feedback).
ibus-1.4.99.20120317-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.