[Uim] keysym addtion

[Etsushi Kato]

Hi,

On 10/10/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> I think that it's a good time to add focus and cursor position
> shift handlings to input contexts because uim API is already
> revised by the recent text acquisition feature. Aggregating such
> interface addition will reduce total development cost.

How about UKey keysym reconstruction at this time?  I'd like to handle
deadkeys, and Japanese Kana keysyms.  Also maybe we should distinguish
KP_* keysyms from numeric keys.

To accomplish this, syncing UKey with all the keysym in X11's
keysymdefs.h and/or GTK+'s gdkkeysyms.h may reduce the cost of further
revision of UKey.  However, since we use scheme internal symbol for
these keysyms as string in key_tab[] on uim-key.c, adding huge table
into key_tab[] consumes memory in libuim, and possibly make key
handling slow.

BTW, it seems compose framework have some physical/logical key
handling and it handles deadkeys, but doesn't seem complete for other
keysyms in X11/GTK+.

A possible idea is that removal of key_tab[] from libuim, and addition
of new alist of keysyms (UKey as a key, and scheme symbol as a value)
into scheme side.  And make this alist extensible (off course)
depending on required IM.  For the UKey definition, add all the key
definition in X11/GTK+'s keysym into UKey in uim.h.

e.g.
  * Initially set default keysym alist with symbols we have in current
key_tab[].
  * If uim-latin is used, it adds alist of 'dead_* symbols into the
default alist automatically.
  * If uim-anthy is used with Kana layout, its module requires alist
of its keysym ('Kana_*) and add them into the default alist
automatically.

In this idea, I assume all the key is correctly configured with
logical mapping in lower layer, or logical mapping is correctly
converted from physical key in scheme side (composer) before handled
in IM.


A second idea is keep current mechanism, and just add UKey_dead* and
UKey_Kana_* symbols for my purpose at the moment.


YamaKen, so here is the question:

  * Is it good time for this (deadkey and Kana key handling), or
should we wait it after merging sigscheme and composer?
  * Do  you have any plan about the UKey keysym reconstruction (more
key handling) with composer framework?


In other words:

  * For the deadkey/Kana (and more) key handling, which do you think
the better path?
     1) Wait for composer framework (although some of the keysyms are
still missing).  Then adding some more keysyms after this.
     2) Adding all the X/GDK keysyms with massive reconstruction with
current uim.
     3) Just adding some of the keys I needed (some of the deadkeys
and Kana keys) for UKey and key_tab[] for now.

Cheers,
-- 
Etsushi Kato
ek.kato at gmail.com