Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (769)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (855)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  [GLFW] keyboard layout  (Read 7385 times)
0 Members and 1 Guest are viewing this topic.
Offline divxdede
« Posted 2014-12-29 21:44:13 »

Hi,

I'm playing with GLFW since it is now the window system for LWJGL.

I intercept key events from a GLFWKeyCallback (i'm not using the unicode char version because i want handle special keys like CAPS_LOCKS...)

I'm french and have an AZERTY keyboard and GLFW don't do any keyboard layout mapping and provide always keycode in the US-Layout (So it's QWERTY).
That mean, if i press "A" on my keyboard i receive the event "Q" from GLFW.

I'm starting to perform the mapping manually regarding the country of the swing method :
1  
InputContext.getInstance().getLocale();

But it's a pain, dirty and i'm not sure to achieve this with a robust solution.

So, have you other alternatives ?

At this time what tried to consider ?
  - using scancode instead of keycode on a way that i can convert it to an awt key code by example (but i don't find anything on it)
  - Be able to change GLFW configration in order that it do the keyboard layout itself (but, it seems that their standard behaviour is to map to US-Keyboard only)
  - using a third-party that will do that better than me Tongue (but at this time i don't find it)

Best regards,

Here my local mapping that i use but it's not cool:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
   private enum KeyboardLayout {
      Qwerty,
      Qwertz,
      Azerty;
   }
   
   private static String         country = null;
   private static KeyboardLayout layout  = null;  


   private static int mapKeyboardLayout( int glfwKeyCode ) {
      if( country == null ) {
         Locale locale = InputContext.getInstance().getLocale();
         if( locale == null ) locale = Locale.getDefault();
         country = locale.getCountry().toLowerCase();
         layout  = getKeyboardLayout(country);
      }
      switch( layout ) {
         case Qwerty : return toQwertyLayout( glfwKeyCode , country );
         case Qwertz : return toQwertzLayout( glfwKeyCode , country );
         case Azerty : return toAzertyLayout( glfwKeyCode , country );
      }
      return glfwKeyCode;
   }
   
   private static KeyboardLayout getKeyboardLayout( String country ) {
      if( country.equals("fr") ) return KeyboardLayout.Azerty;   // FRANCE                                          
      if( country.equals("hr") ) return KeyboardLayout.Qwertz;   // CROATIA
      if( country.equals("si") ) return KeyboardLayout.Qwertz;   // SLOVENIA
      if( country.equals("cz") ) return KeyboardLayout.Qwertz;   // CZECH REPUBLIC
      if( country.equals("hu") ) return KeyboardLayout.Qwertz;   // HUNGARY
      if( country.equals("pl") ) return KeyboardLayout.Qwertz;   // POLAND
      if( country.equals("sk") ) return KeyboardLayout.Qwertz;   // SLOVAKIA (Slovak Republic)
      if( country.equals("DE") ) return KeyboardLayout.Qwertz;   // GERMANY
      return KeyboardLayout.Qwerty;
   }

   private static int toQwertyLayout( int glfwKeyCode , String country ) {
      return glfwKeyCode;
   }
   
   private static int toQwertzLayout( int glfwKeyCode , String country ) {
      switch( glfwKeyCode ) {
         case GLFW.GLFW_KEY_Z             : return GLFW.GLFW_KEY_Y;
         case GLFW.GLFW_KEY_Y             : return GLFW.GLFW_KEY_Z;
         default                          : return glfwKeyCode;
      }
   }
   
   private static int toAzertyLayout( int glfwKeyCode , String country ) {
      switch( glfwKeyCode ) {
         case GLFW.GLFW_KEY_A             : return GLFW.GLFW_KEY_Q;
         case GLFW.GLFW_KEY_Q             : return GLFW.GLFW_KEY_A;
         case GLFW.GLFW_KEY_W             : return GLFW.GLFW_KEY_Z;
         case GLFW.GLFW_KEY_Z             : return GLFW.GLFW_KEY_W;
         // ....... and so one
         default                          : return glfwKeyCode;
      }
   }



Offline CopyableCougar4
« Reply #1 - Posted 2014-12-29 22:06:37 »

I did a quick google, and it seems like you can use the scancode passed in the key callback to get the key no matter what the physical layout is.

Either wandering the forum or programming. Most likely the latter Smiley

Github: http://github.com/CopyableCougar4
Offline ziozio
« Reply #2 - Posted 2014-12-29 22:09:11 »

Fix should be out in GLFW 3.1

https://github.com/glfw/glfw/issues/114

I believe there are other "nice" things in 3.1 so when it is released I suspect LWJGL3 will be quick to pick it up
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline divxdede
« Reply #3 - Posted 2014-12-29 22:34:47 »

I checked the version of GLFW used by my LWJGL version and it's:
  
1  
3.1.0 Win32 WGL VisualC


So, if we read the https://github.com/glfw/glfw/issues/114 , we can see that they fix the behaviour in order to provide only the keycode in the US-Layout whatever you have in your OS.

It seems, that before they fix it, it worked like i would want it work for me :-/

Offline divxdede
« Reply #4 - Posted 2014-12-29 22:35:40 »

Yes, but i don't know how to convert a scancode in a keycode that depends of the current keyboard layout.
Offline Spasi
« Reply #5 - Posted 2014-12-29 22:44:29 »

LWJGL 3 uses a custom GLFW build with all features/fixes added in 3.1. Which means it includes the fix for #114.

With that said, you should never have to map keys between keyboard layouts. There are two separate ways to handle keyboard input:

a) Physical keys. For example, you want the default keys for moving around to be WASD (as they appear on a QWERTY keyboard, which is how GLFW understands it). You use GLFW_KEY_W/A/S/D. Now, lets say a user with an AZERTY keyboards tries your application. When they press ZQSD, you'll still get GLFW_KEY_W/A/S/D in the key callback. The mapping is automatic, you don't have to do anything. The only thing to worry about is writing your app so that it works with the physical layout of a US keyboard.

b) Text input. You have to use GLFWCharCallback or GLFWCharModsCallback. These are keyboard layout and locale dependent, and again, you don't have to worry about specific layouts or mappings.
Offline divxdede
« Reply #6 - Posted 2014-12-29 23:03:38 »

I understood the concept behind their choices,

But If you let the player to choose a key and click on "A" from my AZERTY keyboard. I have to use 2 callbacks (the unicode version + keycode version) in order to be able to show him the "A" (render text) but retains internally the keycode "Q" for catch events accordingly.
In this simple case, i don't found anything that let you to provide a "display name" from a keyCode (that is near the unicode codepoint but maybe i miss it).

In other way, if you have a game (or an application) that don't let the user to configure keys and have an action of the logical key "A" (since it show the user "you can press A for doing you magical stuff"). You must register a char-callback that can return you so many codepoint for the same key (minuscule, majuscule, accents,...) but in this case it would be easier to have a virtual keycode instead of a physical keycode.

In a naive reflection, when they talk about "physical" keys, when we press the real physical key "A" (i see a "A" in my hardware keyboard), we can be able to think about receiving a "A" keycode instead of the "Q"

So, i'm confident with the WSAD common problem, but it don't help me to much :-/

LWJGL 3 uses a custom GLFW build with all features/fixes added in 3.1. Which means it includes the fix for #114.

With that said, you should never have to map keys between keyboard layouts. There are two separate ways to handle keyboard input:

a) Physical keys. For example, you want the default keys for moving around to be WASD (as they appear on a QWERTY keyboard, which is how GLFW understands it). You use GLFW_KEY_W/A/S/D. Now, lets say a user with an AZERTY keyboards tries your application. When they press ZQSD, you'll still get GLFW_KEY_W/A/S/D in the key callback. The mapping is automatic, you don't have to do anything. The only thing to worry about is writing your app so that it works with the physical layout of a US keyboard.

b) Text input. You have to use GLFWCharCallback or GLFWCharModsCallback. These are keyboard layout and locale dependent, and again, you don't have to worry about specific layouts or mappings.
Offline Spasi
« Reply #7 - Posted 2014-12-29 23:32:57 »

I think what you're looking for is glfwGeyKeyName, which has not been added to 3.1 yet, see issue #117.
Offline divxdede
« Reply #8 - Posted 2014-12-30 00:44:11 »

I think what you're looking for is glfwGeyKeyName, which has not been added to 3.1 yet, see issue #117.

this
1  
glfwGetKeyName 
will be an option for performing local keyboard mapping ( at least for printable keys )
But won't help for not printable keys.

Thanks a lot,
Best regards,
Pages: [1]
  ignore  |  Print  
 
 

 
EgonOlsen (1599 views)
2018-06-10 19:43:48

EgonOlsen (1700 views)
2018-06-10 19:43:44

EgonOlsen (1154 views)
2018-06-10 19:43:20

DesertCoockie (1582 views)
2018-05-13 18:23:11

nelsongames (1182 views)
2018-04-24 18:15:36

nelsongames (1705 views)
2018-04-24 18:14:32

ivj94 (2473 views)
2018-03-24 14:47:39

ivj94 (1690 views)
2018-03-24 14:46:31

ivj94 (2771 views)
2018-03-24 14:43:53

Solater (910 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!