Winit: Separate modifier for RAlt

[chrisduerr]

I've been trying to troubleshoot this Alacritty issue and have noticed that when RAlt (or commonly also AltGr) is pressed, that the alt modifier is set as active in the winit events.

In the context of a terminal emulator this is problematic though, since the "normal" Alt key is used to send special escape sequences. As far as I know, the RAlt or AltGr key is mainly used for unlocking additional characters on conventional keyboards, so it's often already handled by the ReceivedCharacter event.

As a solution to this issue, it would be nice if the ModifiersState could differentiate between the normal and the right alt key. This would make it straight-forward to know if the key can be ignored since it's handled by ReceivedCharacter, or if additional escapes need to be sent.

Now it should be mentioned that it would be possible to work around this by tracking the LAlt key and stetting/unsetting the key as hold whenever it's presessed/released. However since the modifiers struct seems to be made to get information about the current modifiers and others might run into similar issues, it might be worth expanding it? Though I can see how keeping the modifiers simple would also be an advantage, so maybe this should be treated as a special case that needs to be handled in Alacritty.

Regarding the actual implementation, this would be a breaking change if the alt modifier is not sent anymore and altgr or lalt would be sent instead. It would also be breaking if a separate enum/struct for the alt modifier would be introduced. One approach for adding this in a backwards-compatible way would be to add the altgr or lalt modifier, but always sending alt too, if it is pressed. If this is a desired feature I'd love to help out myself, though the approach should be determined first.

[anderejd]

753 Is also related to left and right versions of keyboard buttons.

[Osspial]

On German keyboards, can AltGr normally be used in keyboard shortcuts where a normal Alt would be expected? If not, we could ignore AltGr when determining if the alt flag should be set. I can see that being less error-prone than just adding additional lalt and ralt modifiers, since adding those two flags doesn't fix the fact that handling AltGr as Alt is potentially incorrect behavior.

[Osspial]

I just tested it, and it looks like German keyboards indeed do not treat AltGr as Alt for keyboard shortcuts.

[chrisduerr]

@Osspial I didn't even think of that, but I think this should solve the problem too.

As long as the AltGr key is still sent for key pressed/release events it would also still be possible to manually re-add this functionality, should it ever be needed in some special case.

This would be a breaking change though, just to make sure the version number is bumped appropriately.

[Osspial]

@chrisduerr I'll look into what it takes to do this on Windows. Unfortunately, the Windows API doesn't seem to provide a clean solution to this, but Firefox handles it properly and I can look to see what their source code is doing.

As for this being a breaking change - this seems more like a bugfix to me, seeing that the AltGr key is behaving incorrectly compared to other applications and what the user would expect. I'd be comfortable with releasing a fix to this (that doesn't break the API) as a patch release.

[Osspial]

@francesca64 Would you be able to investigate this on MacOS?

[francesca64]

@Osspial yes, though probably not for a few days.

[ncreuschling]

As a regular user of Alacritty I would like to express my gratitude.

[niklas88]

@francesca64, I know you're doing this in your free time and I'm grateful but I've to ask if there's any news on this? This issue is currently preventing me from using Alacritty on Windows (its my main terminal on Linux) and other than not being able to input "@" its already sooo much better than other terminals.

[francesca64]

@niklas88 no news. It would be better for someone else to look into it.