You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to suggest that the configuration view, where we actually change key bindings, shows the actual keyboard layout that is currently active with the OS. The key legends should dynamically adapt to the current OS layout. As it is right now, the editor GUI only shows the fixed ANSI US layout.
In other words, the editor should be a WYSIWYG editor. This is crucial as soon your language or keyboard layout is not US (which is probably true for most users on this planet).
Reason
The current behavior is counter intuitive as the mapping is all based on ANSI US layout. Mapping is difficult as the current key codes are not obvious and require testing e.g. in a text editor. This is because the user is forced to use ANSI-US based editor keys to modify the actual layout. This means the actual key code does not match with the GUI representation in the editor. That's not very nice and user friendly.
I would rank this feature as being more important than the already implemented 3D views of the keyboard. However, the WYSIWYG support has not been implemented yet.
Implementation
Option 1:
The application automatically detects the current keyboard culture and loads the corresponding view. This is simple when the GUI is allowed to render the key legends dynamically. You shouldn't create a complete new graphical view. Only dynamically load the key legends.
Option 2:
The user selects a keyboard layout language from a dropdown list. This will load the corresponding view. This is simple when the GUI is allowed to render the key legends dynamically. You shouldn't create a complete new graphical view. Only dynamically load the key legends.
Option 3:
Allow the user to load a custom language by providing a JSON that defines the legend of each key. The view then dynamically changes the legends on a fixed keyboard layout view. This is simple when the GUI is allowed to render the key legends dynamically. You shouldn't create a complete new graphical view. Only dynamically load the key legends.
The text was updated successfully, but these errors were encountered:
BionicCode
changed the title
Feature request: current key language layout visualization
Feature request: show current keyboard language in the editor (WYSIWYG)
Jan 10, 2025
Definitely agree with this, a hundred percent. But it can't possibly the first time this has come up, so I'm wondering if it's a lack of capacity/contributions-thing 🤷♂️ I'd love to know though.
@strombraaten I guess I have posted that request at the wrong project. Should post it here. Yeah, I think many many users are confused with the ANSI US only layout GUI support. I further guess that the GUI originally wasn't developed with localization in mind (although that doesn't make sense except this project started as a small private tool) and that localization has now become extremely difficult to implement.
Feature
I would like to suggest that the configuration view, where we actually change key bindings, shows the actual keyboard layout that is currently active with the OS. The key legends should dynamically adapt to the current OS layout. As it is right now, the editor GUI only shows the fixed ANSI US layout.
In other words, the editor should be a WYSIWYG editor. This is crucial as soon your language or keyboard layout is not US (which is probably true for most users on this planet).
Reason
The current behavior is counter intuitive as the mapping is all based on ANSI US layout. Mapping is difficult as the current key codes are not obvious and require testing e.g. in a text editor. This is because the user is forced to use ANSI-US based editor keys to modify the actual layout. This means the actual key code does not match with the GUI representation in the editor. That's not very nice and user friendly.
I would rank this feature as being more important than the already implemented 3D views of the keyboard. However, the WYSIWYG support has not been implemented yet.
Implementation
Option 1:
The application automatically detects the current keyboard culture and loads the corresponding view. This is simple when the GUI is allowed to render the key legends dynamically. You shouldn't create a complete new graphical view. Only dynamically load the key legends.
Option 2:
The user selects a keyboard layout language from a dropdown list. This will load the corresponding view. This is simple when the GUI is allowed to render the key legends dynamically. You shouldn't create a complete new graphical view. Only dynamically load the key legends.
Option 3:
Allow the user to load a custom language by providing a JSON that defines the legend of each key. The view then dynamically changes the legends on a fixed keyboard layout view. This is simple when the GUI is allowed to render the key legends dynamically. You shouldn't create a complete new graphical view. Only dynamically load the key legends.
The text was updated successfully, but these errors were encountered: