GNOME Bugzilla – Bug 695049
Can't select m17n input methods for languages that don't have a locale
Last modified: 2013-03-11 13:01:22 UTC
IBus/m17n has some useful input methods for Esperanto. However, it's not possible to directly select these in git master of the regions panel because as far as I can tell it now limits the methods to the ones whose language has a corresponding locale. glibc has historically blocked adding an Esperanto locale with no explanation. Although some distributions manually patch it in, notably Fedora doesn't. In the old control center it was possible to select one of the Esperanto input methods but presumably I won't be able to in the next Gnome. Is there anything we can do about this? http://sourceware.org/bugzilla/show_bug.cgi?id=2135 https://bugzilla.redhat.com/show_bug.cgi?id=684474
Actually it looks like glibc has had a change of heart about accepting locales for artificial languages since the maintainership changed. I've proposed a patch to add an Esperanto locale so if that gets accepted then this won't be such a big deal at least for Esperanto. http://sourceware.org/bugzilla/show_bug.cgi?id=14943
There's an "Other" last row in the chooser which has everything that doesn't have locale data. If you just search for esperanto (after clicking the "…" row) you should also see those entries there.
I don't think that works quite right. If I press the ‘…’ button and search for Esperanto I only get the four keyboard layouts, not the input methods provided by m17n. If I manually generate my own Esperanto locale and run it again then I additionally get the 6 extra input methods from m17n. It looks like the input methods get filtered out by this bit of code: http://git.gnome.org/browse/gnome-control-center/tree/panels/region/cc-input-chooser.c?id=730dbfd75ab04a4b47cb38c805fda305253b2c36#n843 The input method has a language code (eo) so it hits the second branch of the if-statement (if (lang_code != NULL)…). That code then tries to find a locale for that language code, but of course there isn't one so it doesn't call add_widgets_to_table. Maybe it should be changed so that it will hit the third part of the if statement (the bit about ‘add it to the “other” locale’) in that case.
Created attachment 237992 [details] [review] region: Factor out adding ibus engine widgets code
Created attachment 237993 [details] [review] region: Always add ibus engine widgets regardless of locale info This makes sure any engine we don't have locale info for ends up under the Other row. -- (In reply to comment #3) > It looks like the input methods get filtered out by this bit of code: > > http://git.gnome.org/browse/gnome-control-center/tree/panels/region/cc-input-chooser.c?id=730dbfd75ab04a4b47cb38c805fda305253b2c36#n843 > > The input method has a language code (eo) so it hits the second branch of the > if-statement (if (lang_code != NULL)…). That code then tries to find a locale > for that language code, but of course there isn't one so it doesn't call > add_widgets_to_table. Maybe it should be changed so that it will hit the third > part of the if statement (the bit about ‘add it to the “other” locale’) in that > case. Ups, you're right. Thanks for pointing it out.
Those patches work for me. Thanks!
Created attachment 238410 [details] [review] region: Factor out adding source widgets code -- Found a forgotten hunk to consolidate here.
Created attachment 238411 [details] [review] region: Always add ibus engine widgets regardless of locale info -- rebased
Should we consider this for 3.8 ?
(In reply to comment #9) > Should we consider this for 3.8 ? Yes - it's a bug fix without UI changes (well, shows entries that would otherwise be hidden but among hundreds of others...)
(In reply to comment #10) > (In reply to comment #9) > > Should we consider this for 3.8 ? > > Yes - it's a bug fix without UI changes (well, shows entries that would > otherwise be hidden but among hundreds of others...) And it does not only affect Esperanto but also general purpose input methods like latn-post and latn-pre, so it is really nice to have.
Review of attachment 238410 [details] [review]: ::: panels/region/cc-input-chooser.c @@ +775,3 @@ + const gchar *id) +{ + GList tmp = { 0 }; Why set the GList's data pointer here. @@ +776,3 @@ +{ + GList tmp = { 0 }; + tmp.data = (gpointer) id; and then here? Should prev/next be reset as well?
Review of attachment 238411 [details] [review]: Fine.
(In reply to comment #12) > ::: panels/region/cc-input-chooser.c > @@ +775,3 @@ > + const gchar *id) > +{ > + GList tmp = { 0 }; > > Why set the GList's data pointer here. > > @@ +776,3 @@ > +{ > + GList tmp = { 0 }; > + tmp.data = (gpointer) id; > > and then here? > > Should prev/next be reset as well? It's just because add_widgets_to_table() takes a GList with ids to create widgets for. Here I just want to add a single widget so yes, prev/next should be NULL.
> + GList tmp = { 0 }; > > Should prev/next be reset as well? Initialising any of the members of a stack-allocated struct will also reset any of the unspecified members to zero according to the C spec, so this effectively does reset prev/next too. “If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.”
Attachment 238410 [details] pushed as 3dc1968 - region: Factor out adding source widgets code Attachment 238411 [details] pushed as ce5d794 - region: Always add ibus engine widgets regardless of locale info