-
-
Notifications
You must be signed in to change notification settings - Fork 21.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for [ctrl] + [alt] + special character == [Alt Gr] + special character #6851
Comments
Same problem on Win 10, Italian keyboard: can't access Alt-Code characters via Numeric Pad inside Godot's editor. Example: The Bitwise NOT tilde character This is a list of commonly used characters which are not present in non-US keyboards and require an alt-code sequence under Windows OS:
They are all crucial character in programming/development envinroment, yet uneasy to obtain on many keyboards (especially on laptops which don't have numeric pad and require additional keystrokes). Since different keyboard layouts might suffer from different lacks of characters, it would be nice to have Godot editor support standard Windows alt-codes, or (even better) offer some keystroke-combinations customization to make some characters easily reachable. (for example, in SublimeText is rather easy to set up custom key-combination, like Alt' for |
The only other current alternative I can think of is switching the keyboard layout to US-EN keyboard during work sessions, which isn't an ideal solution for other open tools which support alt-codes. |
Is there an ETA on this? I don't know of any workaround. Is it complicated to support this? |
Ok, before Bugsquad intervention about old issues (also, BUMP! 😄 ): this still does not work & still annoy us, not US-keyboard-layout lover. (Godot 3.0.2 stable official) |
I remember looking at this but it's not that easy to fix (at least I couldn't find any good documentation). |
I have this same problem with Spanish keyboard, no Ctrl + Alt support. Godot 3.06 64 bits Windows 10 |
Another bump for this, it's annoying to have to use uncommon / unpractised key combos on a QWERTZ keyboard layout to input symbols frequently needed when coding (~ | { } [ ]). |
This issue still affects both the Godot script editor and the various text editing nodes. (3.2) This unfortunately makes Godot much less useful for making internationally supported applications and games involving lots of text entry. |
I'm surprised that after four years this issue hasn't been solved yet. Also, it's quite rare to find editors that don't support Alt-codes (after all, they are part of the native OS).
Indeed, I agree on this. At least, for me this has been a major draw back that ultimately kept me away from Godot. It's not just because it makes coding a slow and painful process (which does matter), but also due to the fact that it makes Godot a rather US-centric app — i.e., assumes users are working on a US keyboard. I can't wrap my head around this. It's something rare to find in editors, and makes you wonder. |
I didn't even know Ctrl + Alt could be used as an alternative to AltGr until this issue was bumped yesterday 🙂 That said, that combination doesn't seem to work on Linux (using the "French - alternate" keyboard layout). I guess it's a Windows-only thing? Anyway, as @vnen commented a while ago, the issue at hand is non-trivial. We don't have a whole lot of contributors experienced with Windows APIs after all.
Godot doesn't use a standard UI toolkit such as GTK+ or Qt, which may be a reason for this feature being absent. Maybe it's also due to how it handles input (but I don't know exactly why). |
Yes, Alt-codes are Windows only, although often the term is used to indicate any shortcut to access special characters absent in a keyboard. There are some equivalent short cuts on *nix machines, but these might be distro specific; I remember that working on Ubuntu I had to struggle because whenever I needed to access a special char I'd go in «auto-mode» and use the Windows combinations, which of course did not work.
I also think that's the root of the problem. The advantage of using well established UI libraries is that they already take care of this low-level stuff. Alt-codes is usually an expected feature in editors and text input controls, so it's not something you'll see advertised with neon lights in the features list of such libraries (or any editing application), it's just something we all expect to be present, due to usage experience.
Actually, under Windows OS there are multiple ways to access special chars, depending on the required char (ASCII, Unicode, emoji, etc.), and in some cases on the application being used. Probably the most important issue right now is being able to access standard ASCII characters which are required for coding ( |
Thanks for bump. Four years later and I'm still annoyed. (Godot hobbyist but full-time c# dev - so, lots and lots of code typed in Win :) ) |
It can indeed. I think Windows treats Ctrl + Alt and AltGr as functionally equivalent in most situations, with the possible exception of some specific keyboard layouts and system hotkeys. Although I'm not sure of specifics. (I know AltGr + Delete isn't possible though. 😋) However, on some countries' keyboard layouts, constantly using AltGr instead of Ctrl + Alt can be pretty straining on the wrist and fingers. I've also met many people who don't even realize AltGr can be used for anything. Older people, schoolkids, and even some programmers and tech specialists. A possible hack might be detecting when Ctrl + Alt is held and converting it to an AltGr input? Although with no knowledge of how Godot handles key input, I wouldn't be surprised if this is easier said than done, and might just introduce a bunch of other issues. |
I think the problem here is providing a cross-platform solution. The best thing would be to find a ready-made library that leverages each OS native functionality and provides a good customization interface. I don't know of any, but there must something in the wild. |
It doesn't need to be cross-platform since it's a Windows feature. And it also shouldn't require any hacks as the OS should serve the input pre-processed if it's an OS feature, like Linux distros will do whenever you use AltGr or the Compose key to input special characters (which works out of the box on Godot and any Linux application). So this needs looking into how Windows' Ctrl+Alt == AltGr feature works internally, and then try to figure out why it's not working with Godot's input processing. Could be that Windows does not pre-processor the input and lets all applications do the handling manually, but if so that's pretty bad design on their end. If that's the case however, I expect that it should be covered in MSDN, as they usually have fairly decent documentation for Windows APIs. |
Good to know that at least on Linux Alt keys work as expected.
The feature is available in any of Windows OS native text-input controls, coders don't have to do anything special to enable it. But I have no idea how the same functionality can be enabled in custom controls. Probably a good starting point would be to look at some cross platform third party GUI libraries that don't use Win native UI controls, check if they support Alt codes, and if they do find out how they managed that. |
I've been peeking at MSDN documentation on keyboard input; the whole issue seems complicated by the fact that Alt codes work partly due to the keyboard (hardware + driver) itself, and partly due to how the WinAPI interprets these "virtual key" sequences. What I did find, though, is a very interesting document by keyboard manufacturers: this rather lengthy document covers also the topic of special key combinations for generating Unicode chars, and goes into the nitty gritty of how Windows intercepts them, etc., also covering some undocumented features. So the above link might be helpful (and at least it's all in a single page). As of MSDN, these links are probably good starting points: |
solved ctrl + alt + special character Issue #6851
Players of my game mostly use a German keyboard layout and can not enter the "@" character with Ctrl-Alt-Q. Which is pretty bad because they have to enter an mail address to login the game. Too bad that the fix generated some regression issues. :( |
The problem here is that the issue is normally the other way around i.e. people wanting to disable Godot also uses a number of As @akien-mga suggests, it's a bad design on Microsoft's part, but as the link in the OP explains, it was implemented as a work around, because "Originally, US PC keyboards (specifically, the US 101-key PC/AT keyboards) did not have an AltGr key because it was relevant only in non-US markets: US keyboards simply had "left" and "right" Alt keys." Although it's worth noting that "some compact keyboards like those of netbooks, the right Alt key may be missing altogether." [3] Ultimately, having |
I believe on keyboard with an If that is the case, if #43888 is ever merged it could potentially be used to solve this issue. |
Still vast majority of users are BFU and not power users. It work in Notepad, it should work in godot TextBox. Whats the difference, really? (Well - i know what the difference is, you know that too, ordinary user doesnt have slightest idea.) That
Yes, it is: L Ctrl + L Alt + v = (I am literally pressing the keys right here & right now) But I am not sure if it helps at all, to be consistent with windows it doesnt matter which ctrl + alt i press (left or right) - both of them works as Alt Gr, so, whats the difference if you know "its left alt" or "its right alt"? |
What happens in VS code for example? If you have a shortcut bound to ctrl shift V, for example, what will it do? |
Anyway:
Can you be more specific about "normally"? I dont think your linked stack oveflow question with +/- 40 upvotes can represent the general opinion on (yes, poor&flawed, but used*) i18n design choice.
Let me disagree: You are thinking about it like it is some "whole world on/whole world off" checkbox somewhere (in editor / project settings) but that is not the right approach - thats oversimplification of somewhat complex i18n problem. I am not talking about script editor, but mainly I care about ingame textboxes - but because godot editor is "ingame editor by design" in the end it is the same thing. Yes, for foreign keyboard it will be disabled. If you're used to "there arent any ctrl + alt shortcuts because thats shortcut for AltGr" you will be confused when things work differently. It is complex i18n problem and because Godot decided to roll own keyboard setting (because reasons) and ignore every other keyboard settings then ENG setting, we have problem with customers from germany (and... you know... rest of the world...) who cant write Please, be consistent with whole world. On ENG (and other?) keyboard settings yes, disable it. On foreign keyboard settings no, enable it. Its much deeper (and thats why it is problematic) i18n system setting then some checkbox setting in project (or *:By the way, i asked my colegue to write |
@akien-mga alt+2.not.working.mov |
A list of shortcuts conflicting with input:
We probably should change them to something else by default. |
So it really feels like I'm nagging here but the shortcuts seems to reset every time I restart the Godot, should I report a separate issue on that? |
(disregard) |
Operating system or device - Godot version: Windows & non-english keyboard layout - All versions
Issue description: When not using english keyboard, writing special chars like '>' and '<' (and many more) must be done with shortcut (right) Alt Gr + <. Thats normal and fine, but on windows, lots of folks (like me) are used to (left) ctrl + (left)alt + < which does not work and is very annoying (you know, you are used to type code one way for 8+ years and then, this one editor does not support it).
Source: https://en.wikipedia.org/wiki/AltGr_key#Control_.2B_Alt_as_a_substitute
Steps to reproduce:
set non english keyboard (czech in my case)
Godot -> script editor
Alt gr + > = '>'
Ctrl + Alt + > = ''
Every native windows app (eh, native... even GIMP support this):
Ctrl + Alt + > = '>'
The text was updated successfully, but these errors were encountered: