Skip to content
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

Characters requiring Alt do not work #311

Closed
najlkin opened this issue Aug 15, 2024 · 8 comments
Closed

Characters requiring Alt do not work #311

najlkin opened this issue Aug 15, 2024 · 8 comments
Labels

Comments

@najlkin
Copy link
Contributor

najlkin commented Aug 15, 2024

Some characters like backslash '\' require Alt to be pressed with some keyboard layouts (with Czech it is Alt+Q). This does not work since the merge of #294 , because Alt combinations are handled separately before translation to characters. The functions handling the key presses then ignore the modifier, so it is interpreted as 'q' and closes the window instead of setting the light source 😄 .

❓ This bug was introduced in #294

@najlkin najlkin added the bug label Aug 15, 2024
@najlkin
Copy link
Contributor Author

najlkin commented Aug 15, 2024

A possible fix would be to make the whole algorithm less opportunistic, i.e., identify the key combinations including their modifier and let the unprocessed keys combinations to be handled as characters if there is no match 🤔 .

@najlkin najlkin mentioned this issue Aug 15, 2024
12 tasks
@najlkin najlkin changed the title Characters requiring Alt do not work with keyboard layouts Characters requiring Alt do not work Aug 15, 2024
@justinlaughlin
Copy link
Contributor

justinlaughlin commented Aug 15, 2024

Out of curiosity, are you using a Czech keyboard? I'm shocked you discovered this 😆

@najlkin
Copy link
Contributor Author

najlkin commented Aug 15, 2024

No, I was just trying different keyboards all day long, it is such a great fun 😆 ...Kidding, yes, I am using Czech keyboard, even for programming 😯 🤭 , I cannot change it to English, I have tried, but I cannot 😅 . Even when it is sometimes almost literally painful, like using Alt+B/N for braces 🫠

@najlkin
Copy link
Contributor Author

najlkin commented Aug 16, 2024

Another option is to move processing of most of the keys from keyDownEvent() to textInputEvent() by passing the modifiers instead of just a boolean that the keys were processed 🤔 . That would be an easier solution.
Edit: nope, that does not work, Alt+a is translated to '~' on Czech keyboard, so the event is processed as ruler setting instead of axis formatting 🙃

@v-dobrev
Copy link
Member

v-dobrev commented Sep 5, 2024

@najlkin, is this issue under Windows with WSL?

Do I understand you correctly thatAlt+a is indistinguishable from ~ in the Czech keyboard layout?

If that is the case, the use of Alt + key in GLVis is a problem -- before #294, Alt + key combinations were not supported fully and I suspect that's why they used to work (e.g. Alt+a was seen as ~). The need to support Alt + key combinations was introduced in #288 which assigned actions to Alt+a and Alt+c (#294 was merged into #288 to fully support Alt + key combinations).

It does seem strange that you cannot add English keyboard layout in Windows when you are using a Czech keyboard. With a standard English keyboard, you can add keyboard layouts for other languages.

@najlkin
Copy link
Contributor Author

najlkin commented Sep 5, 2024

@v-dobrev , the problem is general, not specific to a platform. It happens under WSL and I just tested also for the native Windows GLVis. It is also not specific to a layout, Alt is often used for different symbols with different layouts.

The case with ~ is special (also only under Linux Alt+a is ~, not Windows) and it is understandable we might have to drop one of the combinations. The solution with passing the modifier to the text input event is risky, because we do not know to what character the key will be translated, so Alt+c or Alt+a will be left for it, but those characters will not ever arrive there due to the translation. If there is a different registered key by coincidence (like ~), it makes some sense, but it is just luck 😏 . However, I just tested that only right Alt does the translation, not left, so I can get both functions 😉 . But this must be tested across platforms...

I was primarily mentioning \, where the current behavior does not make sense, because nothing is registered for Alt+q, it is just the current system, where handlers completely ignore the modifiers in most cases, so it is handled as q and never gets to the text input event. If we were not presuming what will be handled where, which is problematic with different layouts, but we were registering the whole key combinations with modifiers, we would be able to set lastKeyDownProcessed based on that if the key combination was really handled correctly or not. So this I would see as a much better solution.

I checked that Alt handling worked for me in #288 before the merge of #294 , so it is: handling of Alt combinations with a/c on Mac vs. unknown number of broken key combinations with various layouts 😏 . That is not a great deal.

I can switch the layout, but this is not about it. We never asked users to do that and things worked before...

@najlkin
Copy link
Contributor Author

najlkin commented Sep 5, 2024

Ok, I opened #316 for the first possible solution. If Left Alt vs. Right Alt behavior works everywhere, it is fine, I guess 🤔 . Please test it.

@najlkin
Copy link
Contributor Author

najlkin commented Sep 21, 2024

Solved in #316 .

@najlkin najlkin closed this as completed Sep 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants