From: Marcus Sundberg <e94_msu@e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Mon, 06 Jul 1998 15:26:48 +0200

Re: Keyboard Change

Andrew Apted wrote:
> 
> Hi folks,
> 
> Could we please decide the KT_LATIN/KT_LETTER keyboard issue ?  I have
> just "fixed" the X_common/events.c to put the Latin1 keys back where
> they previously were (0xF0xx) -- current programs expect this behaviour
> and AFAIK no decision has been made yet.
> 
> Here's the plan: abolish the KT_LATIN and KT_LETTER defines, and let
> keys like 'A' have their proper unicode value (0x0041).  Much nicer.
> How about it ?

Yes! Please! This is what we should do.

> Making this change also means we need to update the namespace -- we're
> gonna need translation from Linux keysyms -> GGI keysyms and to do that
> we're gonna have to #include both linux/keyboard.h and ggi/keyboard.h.
> 
> The namespace I have in mind is:
> 
>    keys: GGI_KEY_ENTER, GGI_KEY_F1, GGI_KEY_INSERT, ...
>    types: GGI_KT_SPEC, GGI_KT_FN, GGI_KT_SHIFT, ...
>    modifiers: GGI_KM_SHIFT, GGI_KM_CTRL, GGI_KM_ALT, ...

Well, I'd rather have GGIK_ENTER, GGIKT_SPEC and GGI_KM_SHIFT.
But most important of all:
whichever prefix we choose, we should use *_Return, *_Insert
and so on, ie. except for the prefix the names are identical
to X's keysyms. Some reasons for this:
They're just names. Which we choose doesn't really mather,
except for:
There's no point in having a completely new scheme.
For the nearest future most applications that are ported to
libggi will be X-applications, simply because most graphical
UNIX apps are made for X.

Having the keysyms be similiar to the Linux ones has NO
point as no graphic app I know of uses Linux keysyms.
They use SVGALib scancodes. And having libggi keysyms
be similiar to the SVGALIB ones are no good either
as the number of SVGAlib apps are small compared to
the number of X apps.

The whole event-handling system of libggi is _VERY_
similiar to the X one, so if we use the same keysyms
too a lot of developers will not have to learn a new
scheme.

(note that when I'm talking about keysyms above I
ofcourse refer to their symbolic names, not their
value)

//Marcus