Update en-us compose table and add locale tables for xkb engines.

Update en-us compose table and add locale tables for xkb engines.


BUG=RH#1013651
TEST=engine/ibus-engine-simple, src/libibus.so

[Peng, 2013-10-07 15:07:22]

On 2013/10/07 08:38:01, fujiwara wrote:

Could you please add more detail in this CL? explain why need this? what's the
problem of current code? Thanks.

[fujiwara, 2013-10-08 02:58:24]

On 2013/10/07 15:07:22, Peng wrote:
> On 2013/10/07 08:38:01, fujiwara wrote:
> 
> Could you please add more detail in this CL? explain why need this? what's the
> problem of current code? Thanks.

You could refer https://bugzilla.redhat.com/show_bug.cgi?id=1013651 .
The user asks fi-fi compose table on GTK+ applications when
LC_CTYPE=fi_FI.UTF-8.
Probably GTK_IM_MODULE=xim had been used.
Comparing /usr/share/X11/locale/en_US.UTF-8/Compose and
/usr/share/X11/locale/fi_FI.UTF-8/Compose, the most compose keys are integrated
in en-us table now but the the current gtkimcontextsimpleseqs.h is older than
en_US.UTF-8/Compose .

Now I added one fi-fi table and also updated gtkimcontextsimpleseqs.h .
I guess he wants Multi_key + f + i especially.

That report also asks to update compose tables for all locales and I added fi-fi
and el-gr. Other locales and en-us are same.
gtkimcontextsimpleseqs.h is generated by gtk+/gtk/compose-parse.py and el-gr
table is generated by composetable.py in this patch.

I will also try to fix gtkimcontextsimpleseqs.h in GTK+ later.
The user might not use ibus but gtk-im-simple-context however I think it's good
to integrate the compose tables in ibus from X11.

[Peng, 2013-10-08 21:01:40]

https://codereview.appspot.com/14465046/diff/1/engine/Makefile.am
File engine/Makefile.am (right):

https://codereview.appspot.com/14465046/diff/1/engine/Makefile.am#newcode63
engine/Makefile.am:63: composetable.vala \
Can you add a rule to generate composetable.vala?
BTW, it is not necessary to generate composetable.vala in very build? It is for
ibus upstream developers only?

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py
File engine/composetable.py (right):

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode1
engine/composetable.py:1: #!/usr/bin/python
license header

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode17
engine/composetable.py:17: "Usage: ./%s COMPOSE_FILE_PATH" %
os.path.basename(sys.argv[0])
Use ' ' for strings. and other places.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode22
engine/composetable.py:22: if match('^U[0-9a-fA-F]+$', keysym):
r'^U[0-9a-fA-F]+$'

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode27
engine/composetable.py:27: def sort_compose(a, b):
cmp_compose

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode37
engine/composetable.py:37: sys.exit(-1)
Prefer raise an Exception instead of sys.exit()

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode38
engine/composetable.py:38: for i in [0, 1, 2, 3, 4, MAX_COMPOSE_LEN]:
for code_a, code_b in zip(a, b):
  ...

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode53
engine/composetable.py:53: components = split(':', line, 2)
seq, val = line.split(':' 2)

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode99
engine/composetable.py:99: 
if __name__ == '__main__':
    sys.exit(main())

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala
File engine/composetable.vala (right):

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala#newco...
engine/composetable.vala:24: using IBus;
Are those tables useful for other engines (anthy, m17n, and etc)?
If yes, maybe move them to libibus?

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala#newco...
engine/composetable.vala:26: const uint16 pt_compose_seqs[] = {
Can we have a small test to verify the generated table is correct?

For example: Create an EngineSimple and then add a generate table. Send  a list
of key events to EngineSimple, and then verify the output.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala#newco...
engine/composetable.vala:46: const uint16 el_compose_seqs[] = {
This table is big. Does it have duplicated items with the table in
src/gtkimcontextsimpleseqs.h?

[fujiwara, 2013-10-17 08:28:57]

https://codereview.appspot.com/14465046/diff/1/engine/Makefile.am
File engine/Makefile.am (right):

https://codereview.appspot.com/14465046/diff/1/engine/Makefile.am#newcode63
engine/Makefile.am:63: composetable.vala \
On 2013/10/08 21:01:40, Peng wrote:
> Can you add a rule to generate composetable.vala?
> BTW, it is not necessary to generate composetable.vala in very build? It is
for
> ibus upstream developers only?

Now I moved engine/composetable.vala to src/ibuscomposetable.h and added the
rule in the file.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py
File engine/composetable.py (right):

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode1
engine/composetable.py:1: #!/usr/bin/python
On 2013/10/08 21:01:40, Peng wrote:
> license header

Done.
Do you need the header in the script?
If yes, it's good to add the file to EXTRA_DIST in Makefile.am

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode17
engine/composetable.py:17: "Usage: ./%s COMPOSE_FILE_PATH" %
os.path.basename(sys.argv[0])
On 2013/10/08 21:01:40, Peng wrote:
> Use ' ' for strings. and other places.

Done.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode22
engine/composetable.py:22: if match('^U[0-9a-fA-F]+$', keysym):
On 2013/10/08 21:01:40, Peng wrote:
> r'^U[0-9a-fA-F]+$'

Done.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode27
engine/composetable.py:27: def sort_compose(a, b):
On 2013/10/08 21:01:40, Peng wrote:
> cmp_compose

Done.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode37
engine/composetable.py:37: sys.exit(-1)
On 2013/10/08 21:01:40, Peng wrote:
> Prefer raise an Exception instead of sys.exit()

Done.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode38
engine/composetable.py:38: for i in [0, 1, 2, 3, 4, MAX_COMPOSE_LEN]:
On 2013/10/08 21:01:40, Peng wrote:
> for code_a, code_b in zip(a, b):
>   ...

Done.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode53
engine/composetable.py:53: components = split(':', line, 2)
On 2013/10/08 21:01:40, Peng wrote:
> seq, val = line.split(':' 2)

Done.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode99
engine/composetable.py:99: 
On 2013/10/08 21:01:40, Peng wrote:
> if __name__ == '__main__':
>     sys.exit(main())

Done.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala
File engine/composetable.vala (right):

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala#newco...
engine/composetable.vala:24: using IBus;
On 2013/10/08 21:01:40, Peng wrote:
> Are those tables useful for other engines (anthy, m17n, and etc)?
> If yes, maybe move them to libibus?

Done.
But gir does not export the arrays directly so I added some APIs in
ibusshare.[c,h] .

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala#newco...
engine/composetable.vala:26: const uint16 pt_compose_seqs[] = {
On 2013/10/08 21:01:40, Peng wrote:
> Can we have a small test to verify the generated table is correct?
> 
> For example: Create an EngineSimple and then add a generate table. Send  a
list
> of key events to EngineSimple, and then verify the output.

Done.
I added engine/test-compose.vala

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala#newco...
engine/composetable.vala:46: const uint16 el_compose_seqs[] = {
On 2013/10/08 21:01:40, Peng wrote:
> This table is big. Does it have duplicated items with the table in
> src/gtkimcontextsimpleseqs.h?

OK, now I added to check the duplicated items in src/composetable.py and needed
to access src/gtkimcontextsimpleseqs.h by src/composetable.py so
I added ibus_compose_get_compact_table_en_us() for gir.

Previously fi table was generated by manual but now by the script only.
The tables and src/gtkimcontextsimpleseqs.h are not duplicated but it seems X11
has the default compose table and my script does not check it.

[fujiwara, 2013-10-18 09:50:12]

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py
File engine/composetable.py (right):

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode53
engine/composetable.py:53: components = split(':', line, 2)
On 2013/10/17 08:28:58, fujiwara wrote:
> On 2013/10/08 21:01:40, Peng wrote:
> > seq, val = line.split(':' 2)
> 
> Done.

I checked line.split(':' 2) can split more than 3 segments and the change causes
a crash so I reverted the change.

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala
File engine/composetable.vala (right):

https://codereview.appspot.com/14465046/diff/1/engine/composetable.vala#newco...
engine/composetable.vala:46: const uint16 el_compose_seqs[] = {
On 2013/10/17 08:28:58, fujiwara wrote:
> On 2013/10/08 21:01:40, Peng wrote:
> > This table is big. Does it have duplicated items with the table in
> > src/gtkimcontextsimpleseqs.h?
> 
> OK, now I added to check the duplicated items in src/composetable.py and
needed
> to access src/gtkimcontextsimpleseqs.h by src/composetable.py so
> I added ibus_compose_get_compact_table_en_us() for gir.
> 
> Previously fi table was generated by manual but now by the script only.
> The tables and src/gtkimcontextsimpleseqs.h are not duplicated but it seems
X11
> has the default compose table and my script does not check it.

OK, I added check_algorithmically() in comopsetable.py and probably now almost
duplications are removed.

[Peng, 2013-10-18 16:04:14]

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py
File engine/composetable.py (right):

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode53
engine/composetable.py:53: components = split(':', line, 2)
On 2013/10/18 09:50:12, fujiwara wrote:
> On 2013/10/17 08:28:58, fujiwara wrote:
> > On 2013/10/08 21:01:40, Peng wrote:
> > > seq, val = line.split(':' 2)
> > 
> > Done.
> 
> I checked line.split(':' 2) can split more than 3 segments and the change
causes
> a crash so I reverted the change.
It should be line.split(':', 1),

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala
File engine/main.vala (right):

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala#newcode27
engine/main.vala:27: extern static const uint16 ibus_compose_seqs_pt_br[];
I saw you add some functions for getting the table. Why not use them?

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala#newcode82
engine/main.vala:82: 5,
What's the number 5?

https://codereview.appspot.com/14465046/diff/77001/src/Makefile.am
File src/Makefile.am (right):

https://codereview.appspot.com/14465046/diff/77001/src/Makefile.am#newcode151
src/Makefile.am:151: ibuscomposetable.h      \
Add a rule in this Makefile.am to generate ibuscomposetable.h

https://codereview.appspot.com/14465046/diff/77001/src/composetable.py
File src/composetable.py (right):

https://codereview.appspot.com/14465046/diff/77001/src/composetable.py#newcod...
src/composetable.py:444: sys.exit(-1)
return -1

https://codereview.appspot.com/14465046/diff/77001/src/composetable.py#newcod...
src/composetable.py:454: print_compose(ibus_key_list)
return 0

https://codereview.appspot.com/14465046/diff/77001/src/ibus.h
File src/ibus.h (right):

https://codereview.appspot.com/14465046/diff/77001/src/ibus.h#newcode59
src/ibus.h:59: #include <ibuscomposetable.h>
Is it necessary include it here?

https://codereview.appspot.com/14465046/diff/77001/src/ibusutil.h
File src/ibusutil.h (right):

https://codereview.appspot.com/14465046/diff/77001/src/ibusutil.h#newcode54
src/ibusutil.h:54: const guint16 *  ibus_compose_get_compact_table_en_us
Can you merge those functions to one?
For example

ibus_compose_get_compact_table(const gchar* local);
And if local is NULL, it will use the current system local

[fujiwara, 2013-10-21 07:02:33]

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py
File engine/composetable.py (right):

https://codereview.appspot.com/14465046/diff/1/engine/composetable.py#newcode53
engine/composetable.py:53: components = split(':', line, 2)
On 2013/10/18 16:04:14, Peng wrote:
> On 2013/10/18 09:50:12, fujiwara wrote:
> > On 2013/10/17 08:28:58, fujiwara wrote:
> > > On 2013/10/08 21:01:40, Peng wrote:
> > > > seq, val = line.split(':' 2)
> > > 
> > > Done.
> > 
> > I checked line.split(':' 2) can split more than 3 segments and the change
> causes
> > a crash so I reverted the change.
> It should be line.split(':', 1),

You're right. Done.

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala
File engine/main.vala (right):

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala#newcode27
engine/main.vala:27: extern static const uint16 ibus_compose_seqs_pt_br[];
On 2013/10/18 16:04:14, Peng wrote:
> I saw you add some functions for getting the table. Why not use them?

Because vala anyway duplicates the array and does not support the const array.

If you call 'uint16[] table = IBus.compose_get_table_el_gr();' in main.vala,
vala calls '_vala_array_dup1(_tmp21, -1)' and the -1 causes a segv.

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala#newcode82
engine/main.vala:82: 5,
On 2013/10/18 16:04:14, Peng wrote:
> What's the number 5?

See the header of ibuscomposetable.h. It's the number of the compose sequences.

https://codereview.appspot.com/14465046/diff/77001/src/Makefile.am
File src/Makefile.am (right):

https://codereview.appspot.com/14465046/diff/77001/src/Makefile.am#newcode151
src/Makefile.am:151: ibuscomposetable.h      \
On 2013/10/18 16:04:14, Peng wrote:
> Add a rule in this Makefile.am to generate ibuscomposetable.h

Done.
I think we don't have to generate ibuscomposetable.h every time.

https://codereview.appspot.com/14465046/diff/77001/src/composetable.py
File src/composetable.py (right):

https://codereview.appspot.com/14465046/diff/77001/src/composetable.py#newcod...
src/composetable.py:444: sys.exit(-1)
On 2013/10/18 16:04:14, Peng wrote:
> return -1

Done.

https://codereview.appspot.com/14465046/diff/77001/src/composetable.py#newcod...
src/composetable.py:454: print_compose(ibus_key_list)
On 2013/10/18 16:04:14, Peng wrote:
> return 0

Done.

https://codereview.appspot.com/14465046/diff/77001/src/ibus.h
File src/ibus.h (right):

https://codereview.appspot.com/14465046/diff/77001/src/ibus.h#newcode59
src/ibus.h:59: #include <ibuscomposetable.h>
On 2013/10/18 16:04:14, Peng wrote:
> Is it necessary include it here?

Yes because the header needs to be accessed by vala.

https://codereview.appspot.com/14465046/diff/77001/src/ibusutil.h
File src/ibusutil.h (right):

https://codereview.appspot.com/14465046/diff/77001/src/ibusutil.h#newcode54
src/ibusutil.h:54: const guint16 *  ibus_compose_get_compact_table_en_us
On 2013/10/18 16:04:14, Peng wrote:
> Can you merge those functions to one?
> For example
> 
> ibus_compose_get_compact_table(const gchar* local);
> And if local is NULL, it will use the current system local

No, you cannot.
It seems the gir annotation fixed-size is needed.
If only '(array)' is specified and call IBus.compose_get_compact_table() in
python file, it causes a segv.

And I think the en-us table and locale tables have the different table formats
so it's good to have the different APIs between en and others.

I think another idea is that we remove ibusshare.[ch] and rewrite
composetable.py with C language and we don't support python to access the
compose tables.

[Peng, 2013-10-21 15:11:53]

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala
File engine/main.vala (right):

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala#newcode82
engine/main.vala:82: 5,
On 2013/10/21 07:02:33, fujiwara wrote:
> On 2013/10/18 16:04:14, Peng wrote:
> > What's the number 5?
> 
> See the header of ibuscomposetable.h. It's the number of the compose
sequences.
I see. I mean it is not a good idea to use a hardcoded value here. We should
define it in ibus headers.

https://codereview.appspot.com/14465046/diff/77001/src/ibusutil.h
File src/ibusutil.h (right):

https://codereview.appspot.com/14465046/diff/77001/src/ibusutil.h#newcode54
src/ibusutil.h:54: const guint16 *  ibus_compose_get_compact_table_en_us
On 2013/10/21 07:02:33, fujiwara wrote:
> On 2013/10/18 16:04:14, Peng wrote:
> > Can you merge those functions to one?
> > For example
> > 
> > ibus_compose_get_compact_table(const gchar* local);
> > And if local is NULL, it will use the current system local
> 
> No, you cannot.
> It seems the gir annotation fixed-size is needed.
> If only '(array)' is specified and call IBus.compose_get_compact_table() in
> python file, it causes a segv.
> 
> And I think the en-us table and locale tables have the different table formats
> so it's good to have the different APIs between en and others.
> 
> I think another idea is that we remove ibusshare.[ch] and rewrite
> composetable.py with C language and we don't support python to access the
> compose tables.

If in that case, I suggest removing those functions. The API users do not really
need get those table data. They will just pass it to the simple engine. We could
add a API  ibus_engine_simple_add_table_by_local(local) to add the data
directly.

[fujiwara, 2013-10-24 05:39:13]

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala
File engine/main.vala (right):

https://codereview.appspot.com/14465046/diff/77001/engine/main.vala#newcode82
engine/main.vala:82: 5,
On 2013/10/21 15:11:53, Peng wrote:
> On 2013/10/21 07:02:33, fujiwara wrote:
> > On 2013/10/18 16:04:14, Peng wrote:
> > > What's the number 5?
> > 
> > See the header of ibuscomposetable.h. It's the number of the compose
> sequences.
> I see. I mean it is not a good idea to use a hardcoded value here. We should
> define it in ibus headers.

OK, moved it in ibuscomposetable.h.

https://codereview.appspot.com/14465046/diff/77001/src/ibusutil.h
File src/ibusutil.h (right):

https://codereview.appspot.com/14465046/diff/77001/src/ibusutil.h#newcode54
src/ibusutil.h:54: const guint16 *  ibus_compose_get_compact_table_en_us
On 2013/10/21 15:11:53, Peng wrote:
> On 2013/10/21 07:02:33, fujiwara wrote:
> > On 2013/10/18 16:04:14, Peng wrote:
> > > Can you merge those functions to one?
> > > For example
> > > 
> > > ibus_compose_get_compact_table(const gchar* local);
> > > And if local is NULL, it will use the current system local
> > 
> > No, you cannot.
> > It seems the gir annotation fixed-size is needed.
> > If only '(array)' is specified and call IBus.compose_get_compact_table() in
> > python file, it causes a segv.
> > 
> > And I think the en-us table and locale tables have the different table
formats
> > so it's good to have the different APIs between en and others.
> > 
> > I think another idea is that we remove ibusshare.[ch] and rewrite
> > composetable.py with C language and we don't support python to access the
> > compose tables.
> 
> If in that case, I suggest removing those functions. The API users do not
really
> need get those table data. They will just pass it to the simple engine. We
could
> add a API  ibus_engine_simple_add_table_by_local(local) to add the data
> directly.
> 

OK, removed those APIs and rewrote gencomposetable.c and added
ibus_engine_simple_add_table_by_locale.

To run engine/test-compose.vala, I updated IBus-1.0-custom.vala .

[Peng, 2013-10-28 14:57:03]

https://codereview.appspot.com/14465046/diff/377001/bindings/vala/IBus-1.0-cu...
File bindings/vala/IBus-1.0-custom.vala (right):

https://codereview.appspot.com/14465046/diff/377001/bindings/vala/IBus-1.0-cu...
bindings/vala/IBus-1.0-custom.vala:11: [CCode (cname = "IBusComposeTable",
destroy_function = "", cheader_filename = "ibuscomposetable.h")]
Why we still expose those tables. Is it just for testing it in vala?
If yes, could we create a ibus private library for it? And it will not installed
in users' machines.

https://codereview.appspot.com/14465046/diff/377001/src/gencomposetable.c
File src/gencomposetable.c (right):

https://codereview.appspot.com/14465046/diff/377001/src/gencomposetable.c#new...
src/gencomposetable.c:1: /* -*- mode: C; c-basic-offset: 4; indent-tabs-mode:
nil; -*- */
I remember you implement it in python in previous patch se. May I ask why switch
to c?

https://codereview.appspot.com/14465046/diff/377001/src/ibusenginesimple.c
File src/ibusenginesimple.c (right):

https://codereview.appspot.com/14465046/diff/377001/src/ibusenginesimple.c#ne...
src/ibusenginesimple.c:928: void
Maybe it is better to return a boolean value. So caller can know if it adds a
table successfully.

https://codereview.appspot.com/14465046/diff/377001/src/ibusenginesimple.c#ne...
src/ibusenginesimple.c:932: g_return_if_fail (locale != NULL);
Maybe we could support locale == null, so this function will use system local.

https://codereview.appspot.com/14465046/diff/377001/src/ibusenginesimple.c#ne...
src/ibusenginesimple.c:934: #define ENGINE_ADD_TABLE_BY_LOCALE(locale1, locale2)
\
could we define an array in ibuscomposetable.h, which contains all tables and
local names, in this function we could just go through the array to find the
table?

[fujiwara, 2013-10-29 11:27:16]

https://codereview.appspot.com/14465046/diff/377001/bindings/vala/IBus-1.0-cu...
File bindings/vala/IBus-1.0-custom.vala (right):

https://codereview.appspot.com/14465046/diff/377001/bindings/vala/IBus-1.0-cu...
bindings/vala/IBus-1.0-custom.vala:11: [CCode (cname = "IBusComposeTable",
destroy_function = "", cheader_filename = "ibuscomposetable.h")]
On 2013/10/28 14:57:04, Peng wrote:
> Why we still expose those tables. Is it just for testing it in vala?
> If yes, could we create a ibus private library for it? And it will not
installed
> in users' machines.

Yes, it's used for the testing.
gir exposes the definition but not the const entity so need to modify vapi.
I tried to modify test-compose.vala or add another vala to add "[CCode (cname =
"IBusComposeTable"..." but that way causes a build error:

ibuscompose.vala:34.9-34.41: error: A const field requires a value to be
provided
        public const uint16[] seqs_el_gr;
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think vala needs the value besides the definition.

Now I added binding/vala/ibus-private.vapi .

https://codereview.appspot.com/14465046/diff/377001/src/gencomposetable.c
File src/gencomposetable.c (right):

https://codereview.appspot.com/14465046/diff/377001/src/gencomposetable.c#new...
src/gencomposetable.c:1: /* -*- mode: C; c-basic-offset: 4; indent-tabs-mode:
nil; -*- */
On 2013/10/28 14:57:04, Peng wrote:
> I remember you implement it in python in previous patch se. May I ask why
switch
> to c?

The script needs to access gtk_compose_seqs_compact[] in
ibus/src/gtkimcontextsimpleseqs.h to check the duplicated compose sequences
between en-us and other locales.
Now I deleted the APIs in ibusutils.[ch] so I rewrite the python script with
C-langauge so that the script accesses the private array.

https://codereview.appspot.com/14465046/diff/377001/src/ibusenginesimple.c
File src/ibusenginesimple.c (right):

https://codereview.appspot.com/14465046/diff/377001/src/ibusenginesimple.c#ne...
src/ibusenginesimple.c:928: void
On 2013/10/28 14:57:04, Peng wrote:
> Maybe it is better to return a boolean value. So caller can know if it adds a
> table successfully. 

Done.

https://codereview.appspot.com/14465046/diff/377001/src/ibusenginesimple.c#ne...
src/ibusenginesimple.c:932: g_return_if_fail (locale != NULL);
On 2013/10/28 14:57:04, Peng wrote:
> Maybe we could support locale == null, so this function will use system local.

Done.

https://codereview.appspot.com/14465046/diff/377001/src/ibusenginesimple.c#ne...
src/ibusenginesimple.c:934: #define ENGINE_ADD_TABLE_BY_LOCALE(locale1, locale2)
\
On 2013/10/28 14:57:04, Peng wrote:
> could we define an array in ibuscomposetable.h, which contains all tables and
> local names, in this function we could just go through the array to find the
> table?

Done.

[Peng, 2013-10-31 13:13:08]

lgtm

https://codereview.appspot.com/14465046/diff/397001/src/ibusenginesimple.c
File src/ibusenginesimple.c (right):

https://codereview.appspot.com/14465046/diff/397001/src/ibusenginesimple.c#ne...
src/ibusenginesimple.c:936: const gchar *locale1 = locale;
can we just reuse locale instead of adding a new variable locale1?

[fujiwara, 2013-11-01 02:13:35]

https://codereview.appspot.com/14465046/diff/397001/src/ibusenginesimple.c
File src/ibusenginesimple.c (right):

https://codereview.appspot.com/14465046/diff/397001/src/ibusenginesimple.c#ne...
src/ibusenginesimple.c:936: const gchar *locale1 = locale;
On 2013/10/31 13:13:09, Peng wrote:
> can we just reuse locale instead of adding a new variable locale1?

Done.