Index: [thread] [date] [subject] [author]
  From: Marcus Sundberg <e94_msu@elixir.e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Sun, 16 Aug 1998 20:04:58 +0200

Re: keyboard.h changes

> Seriously though, the _API_ deserves special treatment since changing
> that breaks all the programs using that API, which are not under our
> control.

Well, we've been continously breaking things in the libggi API for
eight months now, so it really doesn't matter if we break one 
more thing NOW.
In a few weeks the API should be made final, ideally for many years
on, so this is the last chance we have to remove all stupid things.

> 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.

Yeah, I couldn't agree more. :)

> 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...

Well, the only reason it should matter which system GGI Console uses
if it wishes to be compatible with Linux, and with 2.1 kernels
that's not possible if we wan't unicode, because 2.1.114
linux/keyboard.h contains:
#define KT_LOCK		10
#define KT_LETTER	11	/* symbol that can be acted upon by CapsLock */
#define KT_SLOCK	12
which as an opposite to KT_ASCII looks like things that may actually be
used by applications. (KT_LOCK and KT_SLOCK looks very similiar in purpose
to our GGI_KM_LOCKED and GGI_KM_STICKY btw)

> >  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));
>   }

Ok, GGI_KTYP might be useful in this case, but GGI_KVAL is never:
for latin1 keys GGI_KVAL(sym) == sym, and for unicode keys that
are not latin1, GGI_KVAL will mask off the 8 highest bits.

Also, as all unicode keys, including the latin1 subset, have their
real values  sym <= 0xff  is a better way to check for latin1.

>    #define GGI_UNICODE(x)  ((x) < 0xE000 || (x) >= 0xF900)
> 
> (Just checked, the private zone really is 0xE000..0xF8FF).

Ok fine, it'll let us keep GGI_KT_META == 0xf8 too (is that used
for anything? :)

//Marcus

Index: [thread] [date] [subject] [author]