[Uim] keysym addtion

[YAMAMOTO Kengo / YamaKen]

Hi Etsushi,

At Tue, 17 Oct 2006 22:40:36 +0900,
ek.kato at gmail.com wrote:
> 
> On 10/17/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > >   * 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.
> >
> > Please go ahead with 3). I'm not confident that importing all X
> > keysyms is good or not at now, and I want to keep libuim core
> > unmodified until SigScheme is merged into trunk although your
> > idea which uses the alists to convert the keysyms is a good
> > solution.
> 
> I see.

I have taken a look about your changes under uim/, and I want to
change some key names as the patch attached. Although it makes
the one-to-one exact key name mappings with XKeysyms lost, I
think it's acceptable for uim developers. Consistency of the
naming scheme is more important for IM writers than the exact
mappings. How do you think about it?

And I think that the new UKeys should be added to bottom of the
enum UKey to keep the ABI backward-compatible. Relocate it to
appropriate position when an ABI break occurred.

Finally, please describe about this changes to
doc/COMPATIBILITY. I'll write about the text acquisition and
focus/placement handlers later.

------------------------------------------------
YAMAMOTO Kengo / YamaKen  yamaken at bp.iij4u.or.jp
FAMILY   Given / Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uim-trunk-r3935-ukey-consistency-20061022.diff
Type: application/octet-stream
Size: 4947 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/uim/attachments/20061022/a218616d/attachment.obj