RE: Fw: Re: [AD] messy allegro 5.0 stuff

[Shawn Hargreaves <shargreaves@xxxxxxxxxx>]

Laurence Withers writes:
> I can't see any clean way of handling the `check for a Unicode value, 
> but return a scancode if you can't convert the keypress to Unicode' way 
> of doing things unless the whole thing is returned at once. And I think 
> a single 32-bit int beats anything with structures, pointers or 
> whatever. 

A single int is handy for the "typing in text, and handle arrow 
keys specially", but cannot represent some types of information. 
For instance I can get '\n' by pressing the key with an arrow
drawn on it that lives above my right shift, or the one marked
"Enter" that lives on the numeric pad. Both translate into the 
same UCS4 value, but you need the scancode if you want to 
differentiate  between the two. So the scancodes vs. character
values aren't just alternatives that apply to one key or another,
but can sometimes both be required at the same time.

The Curses keyboard API went down the route of returning ASCII
characters for most things, or special values for things like
the arrow keys, and it doesn't work especially well. The choice
of which things are ASCII and which are control keys is too 
specific to the hardware and app for which it was designed, and
causes big problems for people who have different assumptions
(just ask anyone who's tried to port a DOS text mode program to 
run in the Linux console :-)

Much better IMHO to always provide both raw and translated 
values in parallel, and let the user make the choice of which
they want for each individual key.


-- 
Shawn