Re: [AD] XIM patch for Allegro 4.1.x

[Julien Cugnière <jcugniere@xxxxxxxxxx>]

Elias Pschernig a écrit :

> - pckeys isn't linked into the X11 version anymore

Hmm, this generates lots of "undefined reference" errors during the 
compilation of setup/keyconf.c. This utility relies on _key_ascii_table and 
co., which are all defined in pckeys.c.

> - no more key[0] presses are possible
> - the set_locale and french numbers issues
> - adding 8 KEY_UNKNOWN keys to be used in X11, which else runs out of
>   keys on my 123 keys keyboard
> - scancode_to_ascii now works at least for a few keys even if the
> keyboard driver doesn't implement it (X11 and OSX, probably also linux
> console, didn't check yet)

Nice!

>
> More serious changes:
> - new function: char const *scancode_to_name(int scancode);

Personnaly, I'm all for it. But there is a small typo in the patch, in 
_keyboard_common_name[]: "KEy106". 

> So, I propose this new function, which will supercede scancode_to_ascii.
> It will return a pointer to a static string with the name of a key. For
> most keys this will be just the same as scancode_to_ascii, but it will
> work for every key, i.e. also keys like F1..F12, Enter, Tab, Shift,
> Control and so on. So a keyboard configuration now just needs to use
> this function, and will display localized string names. In X11, it's
> implemented with KeysymToString, in pckeys based drivers it just works
> like the method users had to do manually with scancode_to_ascii before.

The only problem with KeysymToString is with modifiers keys: KEY_LWIN and 
KEY_RWIN are named "Super_L" and "Super_R", and KEY_ALTGR is named 
"ISO_Level3_Shift" (!). It might be better to use our names where possible, 
and use KeysymToString for the rest.

> - updated exkeys to demonstrate keyboard_lowlevel_callback and
> scancode_to_name

Here are a couple things I noticed in the example:

(1) Unfortunately, drawing from a callback doesn't work, not even in X :-(. 
The program sometimes aborts when I press keys, or hold them down. Doesn't 
always happen, though...

(2a) During the "press a combination of numbers" part, keys (not just numbers) 
sometime get "stuck". They appear pressed even after you've released them. 
This doesn't happen anymore if I put a "rest(0)" inside the loop, or remove 
the keypress_handler.

(2b) Also, with or without the keypress_handler, this part of the example is a 
bit "unresponsive": when pressing a number key, there is sometimes a small 
delay before the appearance / disappearance of the number on the screen. 
Again, this doesn't happen anymore if I put a rest(0) in the loop. But IIRC, 
unresponsive input when drawing in a tigh loop is a long standing issue, no ?

(3) The example will crash if scancode_to_name() returns NULL. This happens 
for me for the "Power", "Sleep" and "Wake" keys. They get assigned the 
KEY_YEN, KEY_KANA and KEY_CONVERT constants, but scancoded_toname() returns 
NULL, and the keypress_handler crashes, presumably in ustrzncpy().

-- 
Julien Cugnière