[AD] [ alleg-Bugs-2864320 ] KEY_TILDE has nothing to do with tilde in NON-US keyboard

["SourceForge.net" <noreply@xxxxxxxxxx>]

Bugs item #2864320, was opened at 2009-09-22 13:42
Message generated for change (Comment added) made by elias
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=2864320&group_id=5665

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: aapoaapo (aapoaapo)
Assigned to: Nobody/Anonymous (nobody)
Summary: KEY_TILDE has nothing to do with tilde in NON-US keyboard 

Initial Comment:
Allegro version 4.2.2-2ubuntu1

I'm using keyboard layout SVE/FI. http://en.wikipedia.org/wiki/File:KB_Sweden.svg
In allegro there are KEY_TILDE, but it is not pointing tilde nor button-left-to-1. (§ in my keyboard).

I attached simple application which first print KEY_TILDE and then reads keyboard and prints scancodes of pressed keys.


When I start application it says:
Scancode for the key next to the 1 is according to allegro: 60

Button next to 1 says: Scancode: 74 (unicode: 167 [�])
backslash says: Scancode: 60 (unicode: 92 [\])
tilde says Scancode: 66 (unicode: 126 [~])


----------------------------------------------------------------------

Comment By: Elias Pschernig (elias)
Date: 2009-09-22 20:56

Message:
Yes, all KEY_* constants which are not assigned to anything else in X11 are
then randomly assigned. And because Allegro has no KEY_PLUS (because the US
layout doesn't have a plus key, only KEY_EQUALS), it means there is no
obvious choice for the the key which produces a plus. So it also gets
randomly assigned. And in the end KEY_TILDE ends up being the scancode for
the plus key.

A possibilities to fix this would be to add a KEY_PLUS which is produces
for that key and then have KEY_TILDE do nothing at all. However, we only
have 128 possible keys in Allegro, so we don't have enough room to add all
possible KEY_* constants for all layouts.

So, yes, I would agree that it is a problem, but not one I can see an easy
solution for. Either we say KEY_TILDE is the key to the left of 1, but it
would require quite some effort to implement for X11. Or we say KEY_TILDE
is the key which produces a ~ character, but then there's the problem that
many layouts don't have that key - so hardcoding it in your program
wouldn't be a good idea.

----------------------------------------------------------------------

Comment By: aapoaapo (aapoaapo)
Date: 2009-09-22 19:50

Message:
As you said, my keyboard doesn't have key 'KEY_TILDE', I can still produce
tilde, but I use key named diaeresis.

And this is funny, I added these rows
                if (scancode==KEY_TILDE)
                        printf("Scancode_to_name: %s \n",
scancode_to_name(scancode));

Now when I press '+' (it is used also to produce '?' and '\'), it is
recognized as KEY_TILDE. But scancode_to_name says 'plus'. 


Yes, configurable keys in games are nice, but I still think that there is
problem in allegro. Or should I use only unicodes, not scancodes at all?


----------------------------------------------------------------------

Comment By: Elias Pschernig (elias)
Date: 2009-09-22 17:49

Message:
Yes, that's expected. The intended behavior would be for KEY_TILDE to mean
the key which produces ~, not the one near 1.

To recognize a new uncoide symbol, you would have to send a patch which
modifies the table at the beginning of xkeyboard.c accordingly:

http://alleg.svn.sourceforge.net/viewvc/alleg/allegro/branches/4.4/src/x/xkeyboard.c?revision=12197&view=markup

However, looking at the keyboard map link you provided above, there simply
is no key which produces ~ (there's one for " which produces ~ with the
third level chooser, but that would be KEY_QUOTE or something already).

RIght now the best is to make the keys in your game configurable (use the
scancode_to_name function to display the proper name for a pressed key) -
then users at least can configure things so they work. Of course it would
be nicer to autodetect common keyboard layouts and provide premade mappings
instead of assuming US - right now Allegro won't help with that at all.

I'll set the bug to wont fix for now, unless you have an idea/patch how we
could fix it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=2864320&group_id=5665