3D editor freelook does not work correctly before changing editor shortcuts on non-QWERTY keyboards

[Nutriz]

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Any OS, godot 3.0

Issue description:
Keys binded to the 3D freelook are wrong with AZERTY keyboard.

Solution :

• auto-detect the keyboard type (or use current user language) to sets propers key for logic freelook
• Allow the user in Editor settings to changes keys for freelook
• Bind freelook to LEFT UP RIGHT DOWN keys

[toger5]

I think LEFT UP RIGHT DOWN should be added. that is useful anyways and the easiest fix.
How are other applications (games) handling AZERTY keyboards? Do they autodetect and remap the keys?
If not I would just expose the freeload keys to the shortcut section. If all of them do and ppl using AZERTY are used to that it might be worth it to add a auto detection.

[Zylann]

All freelook keys can be rebound in editor shortcuts. If you have problems with AZERTY, it could not only concerns freelook, but all shortcuts involving character keys... unless they go through a different process?
@toger5 freelook, not freeload, you do the mistake so many times :D

[toger5]

@Zylann i do? Damn it...
I really should stop using github on my phone...
Akien mga also blamed me already for not beeing able to type correctly...

Cool that remapping is already supported.
@Jerome67000 is that already a solution for u?
I think we also could add the additional UpDownLeftRight keybindings...
If you guys think thats a good improovement.
Otherwise other keyboard types need to remap (or just switch to us keyboard (thatd what i did ;) ))

[bruvzg]

Some keyboard type detection and remapping code for Window and macOS already there, but it is used only on macOS.

[Calinou]

This bug occurs in both the editor and exported games. It's really annoying (I'm an AZERTY user as well), since it requires you to re-bind most keys in programs which don't support keyboard layout translation.

Note that the key configuration dialogs should display the key the user will have to press to trigger the action (regardless of the chosen keyboard layout, it should also work if the user switches between layouts). For example, if the user binds Z to move forward, this key will have to be displayed in the GUI, instead of W (as that would be the key on the same position, but on QWERTY).

[Nutriz]

@toger5 yes this solution can be viable :).

Just in case we change for LEFT UP RIGHT DOWN, be care because for the moment it's used to switch from 3D view to the left or right panel. BTW I don't think that is the best way to solve this problem. Using auto detect to setup freelook to QZDS when AZERTY is a smatter way and user don't need to setup manually/user don't think "whats this buggy engine" :).

[akien-mga]

Well it's not a bug, just a missing functionality. AZERTY users (of which I am) know well enough that they can't expect software to cater automatically to their buggy keyboard layout, especially FPS/TPS using WASD for movement (and incidentally, our freelook controls).

Either we implement keyboard type detection and conversion logic on all platforms as outlined by @bruvzg (in which case it's a feature request that goes far beyond the scope of the freelook usability), or we can add presets in the editor settings for QWERTY / QWERTZ / AZERTY to automatically swap the relevant keys. The former would be the best solution, and could be exposed for games and make internationalization a lot easier, but should likely be discussed in its own issue.

[Zylann]

Fun fact: I am an AZERTY user and I coded the part where it polls the keys, and I set the default values to be QWERTY because I could set only one default set of keys (just like other hotkeys assume this layout to nicely line up). All of that knowing that these are rebindable anyways, because it's the simplest solution.
It would be nice though if EditorSettings could get the editor's language and setup the default values with keyboard layout in mind.
Bind arrow keys works around this but nobody use them in first-person so people would want to rebind anyways.

[bruvzg]

@green-coder Dvorak layout selected from macOS settings works ok form me (3.1 master and 3.0.2 stable), key are detected as they displayed in settings preview, both in editor input and key mappings. macOS 10.13.3 (17D102), with QWERTY PC keyboard.

[bruvzg]

@green-coder That's standard Dvorak, if you have "Programmer Dvorak" variant with ; in the start of first row instead of ', I guess it won't be detected correctly, Godot currently detect only limited set of layouts (os_osx.mm#L2125-L2137), everything else is detected as QWERTY.

[green-coder]

Hi. I moved my comment to #808.

[green-coder]

Ctrl+S is not recognized properly, I have to press Ctrl+O instead (that's the position of the S in QWERTY and AZERTY).

[bruvzg]

@green-coder please test #17827 with your keyboard.

[fire]

This issue still happens.

[clarfonthey]

I feel like the best way to deal with this would be to separate scan codes (physical key locations) with symbols (what's drawn on the key). Action mapping should be done by scancode (i.e. pressing A on AZERTY would be the same as pressing Q on QWERTY) whereas events will still have the symbol for when you actually want to type something.

[Calinou]

@clarfonthey Physical scancodes are already supported in master, but aren't supported in 3.2. (This most likely won't be backported due to significant changes to the input system required.)

We could fix this with the default key bindings in 4.0, but the current editor shortcut remapping dialog doesn't support inputting physical scancodes. Also, we need to handle conflicts with other non-physical keys that may be bound by default.

[clarfonthey]

Oh, nice!

Yeah, physical scancode support is definitely the solution for this, and I'm glad it's coming to 4.

[starry-abyss]

Also, we need to handle conflicts with other non-physical keys that may be bound by default.

What conflicts? Is it not possible to convert all shortcuts of Godot to layout-independent and only leave the things related to texts (like input fields)?

[Calinou]

What conflicts? Is it not possible to convert all shortcuts of Godot to layout-independent and only leave the things related to texts (like input fields)?

In applications, some shortcuts rely on their key letter to be easy to understand. For instance, if you assign M to a "move" shortcut, you wouldn't want it to move to a different letter depending on the keyboard layout. Otherwise, the shortcut becomes harder to remember depending on the user's keyboard layout.

This is different in games where the physical key location generally more important than its intended meaning.

[Shadow8472]

Tangent issue, but I use my mouse to the left of my keyboard, and wasd is quite uncomfortable for me. Thanks for the tip about "editor shortcuts."

[Calinou]

As of 4.0.beta17, the editor now allows assigning physical key shortcuts in the Editor Settings' Shortcuts tab. The main challenge for providing this configuration by default is assigning shortcuts that use physical key inputs by default. It should be possible but not trivial – you will need to create the Shortcut manually, rather than use a predefined macro.

Feel free to open a pull request for this if you manage to 🙂

Freelook shortcut defaults are configured here:

godot/editor/plugins/node_3d_editor_plugin.cpp

Lines 5050 to 5055 in 2fdaf29

	register_shortcut_action("spatial_editor/freelook_left", TTR("Freelook Left"), Key::A);
	register_shortcut_action("spatial_editor/freelook_right", TTR("Freelook Right"), Key::D);
	register_shortcut_action("spatial_editor/freelook_forward", TTR("Freelook Forward"), Key::W);
	register_shortcut_action("spatial_editor/freelook_backwards", TTR("Freelook Backwards"), Key::S);
	register_shortcut_action("spatial_editor/freelook_up", TTR("Freelook Up"), Key::E);
	register_shortcut_action("spatial_editor/freelook_down", TTR("Freelook Down"), Key::Q);