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

[Laurence Withers <lwithers@xxxxxxxxxx>]

In reply to Shawn Hargreaves <shargreaves@xxxxxxxxxx>:
>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.

Somewhere in the small print in that sample API, I wrote that things
like escape, enter, etc. (anything unprintable is probably a good
generalisation) would be returned by scancode, not unicode. So using
that single function it would be possible to differentiate between the
two keys.

This also maps nicely onto C's flow controllers, so I can write:

  key = al_read_key();

  if(key & 0x80000000) {
    /* non-printable character, like enter */

    switch(key & 0x7FFFFFF) {
      case KEY_ENTER:
      case KEY_PAD_ENTER:
        ...;

      default:
        ...;
    }
  } else if(key) {

    /* unicode value */
    ...;

  } else {
    /* no key was pressed at all */
    yield_timeslice();
  }

>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 :-)

The Curses keyboard API has some really serious problems, not least of
which is its reliance on 8-bit ascii values. As a university project, I
need to write a text editor. I have heavily based mine on FED, which is
my editor of choice (so that's two users ;^) ), and this is where I have
gained much of my keyboard experience.

Curses returns its special keys as ESC followed by a sequence. This
sequence isn't the same between different systems; so on SunOS, the
return value will be quite different for certain keys (eg. arrow keys)
than on Linux. It also returns escape as ESC, so you need to have timers
and things to check if there is a sequence following it. This is clearly
not an acceptable way of doing things, and is why lots of old
applications use ctrl-a, ctrl-f, ctrl-n, etc. for navigation; they are
simple to interpret, and the same between all systems.

My editor therefore has different keyboard drivers; it uses curses if it
can't find anything else, dumbed-down curses for SunOS (I *really* hate
that OS), and a specific Linux keyboard driver on Linux. I also decided
to use a structure for keypresses:

struct key {
  int ch;           /* unicode */
  int raw, flags;   /* device-independent scancode, modifiers */
};

I regret this very much now, and I will change it later (once the
project is handed in anyway!). It has been a horrible, horrible
experience using this structure; the code is a real mess.

Anyway, enough ranting...

Bye for now,
-- 
Laurence Withers, lwithers@xxxxxxxxxx
                http://www.lwithers.demon.co.uk/

Attachment: signature.asc
Description: PGP signature