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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Bugs item #2864320, was opened at 2009-09-22 13:42
Message generated for change (Settings changed) 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 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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/