Bug 749497 - ibus-gnome3 shows xkb options with empty strings
ibus-gnome3 shows xkb options with empty strings
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ibus (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: fujiwara
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-27 05:04 EDT by Daiki Ueno
Modified: 2013-02-19 07:33 EST (History)
4 users (show)

See Also:
Fixed In Version: ibus-1.4.99.20120317-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-11 22:30:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot of ibus-gnome3 menu (58.40 KB, image/png)
2011-10-27 05:04 EDT, Daiki Ueno
no flags Details

  None (edit)
Description Daiki Ueno 2011-10-27 05:04:34 EDT
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:
Comment 1 fujiwara 2011-11-02 04:25:56 EDT
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, ∅, ∅)' ?
Comment 2 Daiki Ueno 2011-11-07 20:10:37 EST
(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)" ?
Comment 3 fujiwara 2011-11-07 20:44:58 EST
(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.
Comment 4 Daiki Ueno 2011-11-08 04:03:35 EST
(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.
Comment 5 fujiwara 2011-11-08 05:36:34 EST
(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.
Comment 6 Fedora Update System 2012-03-18 06:12:47 EDT
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
Comment 7 Fedora Update System 2012-03-18 15:33:53 EDT
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).
Comment 8 Fedora Update System 2012-04-11 22:30:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.