From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Sun, 07 Mar 1999 22:01:11 +0000

Re: Dead keys

teunis wrote:
> 
> On Sun, 7 Mar 1999, Marcus Sundberg wrote:
> 
> > Andrew Apted wrote:
> > >
> > > Marcus writes:
> > >
> > > >  How do we want to support dead keys?
> > > >
> > > >  "sym" is fairly obvious, GIIK_VOID when a dead key is pressed and
> > > >  then the symbol when the next key is pressed. What about "label"?
> > > >  People might have both normal and dead versions of the same key,
> > > >  so we need labels for them.
> > >
> > > No, labels aren't affected.  There is only one label per key (so you can't
> > > have "normal and dead versions").
> 
> [clip]
> > > Hehehe, it's funny you say that, we used to have it (from linux: KT_DEAD).
> >
> > I know, but then it wasn't defined what purpose it had in the GII API,
> > and the code badly needed a cleanup as you know.
> >
> > > There isn't really a big need for it IMHO, either you know the dead key
> > > (e.g. DIERESIS) and handle it in a switch() statement, or you don't know
> > > it and you ignore it.  Hmmm... do _applications_ really want to know ?
> > > I don't think so.
> >
> > As mentioned above they'll want to know the label in case there
> > is another (undead? ;) key with the same label.
> >
> > > Now, should we add code to e.g. linux-kbd to do dead key processing ?
> >
> > Yes, that's the last piece missing before LibGII has the best keyboard
> > handling system in the known universe. ;-)
> 
> So when will libGII support asian keyboards?

When someone is interrested in having it and is able to provide any
info about how such a thing works. (Or even better, can provide the
code to do it)

I'd love to support everything there is, but I can only code things
I know about.

> >From browsing the Java-1.2 sources it seems there's a number of extra keys
> and/or capabilities on some of those systems...
> Just curious that's all...
> (I've only seen a 386/laptop (JDOS) and stroke-based Chinese keyboard..
> and neither for any length of time)
> 
> [where frequently a graphical database is a necessity to select which one
> of many possible characters fits the current selection....]

In any case it most likely requires support from the OS, and when that
is available and the API is documented we can support it too.
The X input code seems to support Katakana by the way.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se