GLVis / glvis

Lightweight OpenGL tool for accurate and flexible finite element visualization
http://glvis.org
BSD 3-Clause "New" or "Revised" License
263 stars 53 forks source link

Fixed Alt handling to allow layout translation #316

Closed najlkin closed 2 months ago

najlkin commented 2 months ago

Fixed Alt handling to allow key translation for different layouts by passing modifiers to the text input event.

👉 Please test on different platforms. On Windows+WSL or Linux: Left Alt does not translate the key and Right Alt (AltGr) does translate the key.

❓ This is a possible fix for #311 .

tzanio commented 2 months ago

This doesn't seem to work on Mac -- I tested e.g. Alt+c and nothing happens

najlkin commented 2 months ago

Left or right Alt? ... if they are on Mac 😅

tzanio commented 2 months ago

Either left or right option key (there is no Alt on Mac)

najlkin commented 2 months ago

Hmm, that matches, I have found online that there are special symbols mapped to keys on Mac without making a difference between left and right option. So the only way I see is to guard the condition for Mac to return the functionality with localized layouts at least for Linux and Windows users? ðŸĪ”

najlkin commented 2 months ago

Ok, this is a more elegant solution and also works for Windows or Linux users who do not know the difference between left and right Alt 😁 . It stores the physical key from keyDown as a backup, so if translation of the key gives some weird symbol on Mac or accidentally use the wrong Alt on Windows or Linux with some localized layout 😏 , it returns to handling of that one in textInputevent (like if it was in keyDown) 😉 .

tzanio commented 2 months ago

Maybe I am doing something wrong, but this also doesn't work on a Mac: "option+c" acts like "shift+c" and similarly for "option+a"

najlkin commented 2 months ago

Ahh, I stored the physical key, which is always capital 😅 . Now it must work, otherwise... ðŸĪŠ

tzanio commented 2 months ago

Ok, it seems to work with https://github.com/GLVis/glvis/pull/316/commits/031ca5c1c63f24d12b167b908299500d40c07249

v-dobrev commented 2 months ago

I'm testing this with a native Windows build with MSVC and both Alt+a and Ctrl+a do not work. I suspect Ctrl+a does not work on other platforms either since it does not generate text-input event.

v-dobrev commented 2 months ago

Just tested on Mac and can confirm that Ctrl+a does not work there.

najlkin commented 2 months ago

Hmm, that Ctrl can be separated, because it is not used for characters translation, but that Alt is a trouble ðŸĪ” . Have you tried both, left and right?

najlkin commented 2 months ago

If it does not work with neither of them, we may let pass only right Alt to the text input event, because only that one does the translation anyway, so at least the left Alt will work on Windows ðŸĪ” .

najlkin commented 2 months ago

Ok, so I basically reverted that to handle Ctrl, Left Alt and Gui keys in the key down event as before. Only Right Alt is passed to the text input event as only that one does the translation of the characters anyway. So at least Left Alt should work on Windows now 😉 and I guess that Right Alt does not generate text input events as there is nothing mapped to the key by the layout. So when there will be something like with some localized layout, it will generate that event and will work as intended 👍 .

najlkin commented 2 months ago

Btw, is Ctrl+A documented? I do not see it anywhere... ðŸĪ”

v-dobrev commented 2 months ago

Hmm, that Ctrl can be separated, because it is not used for characters translation, but that Alt is a trouble ðŸĪ” . Have you tried both, left and right?

Neither the left nor the right Alt are generating text-events on Windows with the MSVC build.

v-dobrev commented 2 months ago

Btw, is Ctrl+A documented? I do not see it anywhere... ðŸĪ”

I just pushed some documentation for it in README.md.

najlkin commented 2 months ago

Thanks for testing, @v-dobrev, and fixing that documentation 😉 . Merging now.