From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Mon, 17 Aug 1998 00:57:37 +1000

Re: keyboard.h changes

Marcus writes:

>  > I'm a bit pissed off.  Changes to the API, especially when they break
>  > things (such as removing NORMAL out of the modifier names) should be
>  > discussed first, implemented second.
>  
>  Please don't be. I didn't mean to just change things without
>  discussion. It's just that sometimes you get more done if you
>  change things first and then change back the things that
>  makes people want to strangle you. ;-)
  
Hehe.  

Seriously though, the _API_ deserves special treatment since changing
that breaks all the programs using that API, which are not under our
control.  I certainly know what a PITA it is bringing up every little
change for discussion, believe me.

>  > >  I've also made it Unicode compatible by shifting the "typ" 16 bits 
>  > 
>  > It was already Unicode compatible.  The range U+E000 - U+F800 is the
>  > "application private zone".  Admittedly we had overstepped the mark, but
>  > that was easily fixed (e.g. starting at 0xE000 instead).
>  
>  Ok, I didn't know that.
>  Then there's no problem to change it back (it's just three
>  lines of code in the entire CVS tree)

OK, please do.

>  I'll also change
>  #define GGI_KT_META     0xf8
>  #define GGI_KT_ASCII    0xf9
>  #define GGI_KT_BUTTON   0xfc
>  to 0xe0, 0xe1, 0xe2 respectively, and

GGI_KT_BUTTON should be removed.  The only thing that ever used it was
the EvStack joystick driver, but I've come to the conclusion that
sending key events for joystick buttons (but not mice buttons...) is
a really braindead thing to do.  [Joysticks should be first class
citizens with their own events, but that's another debate...]

Personally I'd like to move away from the Linux keysyms and the crap
they contain (like the big gap between K_F20 and K_F21 -- just crazy, or
the KT_CUR type with only four keys in it), but this depends heavily on
whether GGI Console will be using them...

>  Also we must document that GGI_KTYP and GGI_KVAL is only
>  useful when GGI_NORMALKEY is false

Not really, e.g. :

   if (GGI_KTYP(sym) == GGI_KT_LATIN1) {
      printf("Hey, a Latin1 character '%c' !\n", GGI_KVAL(sym));
   }

>  (and btw, shouldn't we
>  change GGI_NORMALKEY to GGI_UNICODE? Makes sense to me at least)

Funnily enough, I did have it as K_ISUNICODE() in the EvStack sources at
one time.  Yeah, GGI_UNICODE() is fine with me.  Seeing that 0xE000 and
0xF800 are particular Unicode values (and not related to KTYP/KVAL), I'm
thinking this :

   #define GGI_UNICODE(x)  ((x) < 0xE000 || (x) >= 0xF900)

(Just checked, the private zone really is 0xE000..0xF8FF).

>  Hmm, that seems correct. I wonder if existing Linux-apps are smart
>  enough to work if I change my keytable. ;)

I think they will.  Apart from LibGGI, the only other main users of
linux keysyms are linux itself and X.

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/