Inconsistent modifiers on MacOS

[almarklein]

Ref pygfx/pygfx#1249

Context

Modifier keys on MacOS are tricky. The command key (⌘) on a mac keyboard very often plays the role of the control key on normal keyboards (e.g. ⌘-c and ⌘-v for copy and paste). But not always (interrupting a process in a terminal is usually control-c). The option key (⌥) plays a role very similar to the Alt key on other keyboards.

Problem

The current situation:

• GLFW reports they keys as they are: ⌘ -> meta and control -> control and option -> alt.
• It looks like Qt tries to be smart and reports: ⌘ -> control and control -> meta.
• Browsers report keys as they are (like glfw).
• btw, the meta key is The windows key (⊞) on normal keyboards.

In glfw we currently pass the keys as they are reported by the backend, but this is a problem, since it means the events are not consistent across backends. I consider this more important than being consistent with the backend, as users can always capture native backend events.

How to fix (proposal)

Introduce a new modifier identifier called something like 'primary', which means ⌘ on mac, and control on other devices. The 'raw' key should still be present, but represent the real key.

Some ways we could go about this:

• Simply add this to the modifiers, so 'primary' in the list together with 'Control' or 'Meta'.
  • The disadvantage is that code that checks the full modifier list (like the Pygfx controllers) will break.
• An extra modifiers2 field that has 'higher level' modifiers, where the key that 'primary' replaces is not present.
  • Need better name.
• An extra primary_down field to the event object.
  • We should probably also have shift_down then too, for consistency.
• Other ideas welcome ...

Rolling this out with minimal breakage can be tricky. We have some changes/improvements to the event system in the pipeline; that could be a point where a breaking change is best done.

[almarklein]

BTW: plugging a regular keyboard in a mac will make the Windows key take the role of the Command key, so it gets even weirder. And then there are people who may have rebinded a key on the OS-level.

Maybe we (and downstream code) should assign the same behavior to 'control' and 'meta'. That way there is pretty good consistency, and it works pretty well, since the Windows key is not normally used as a modifier, and the Control key on MacOS is also not used a lot (except Control+click means right click, because mac mouses have/had just one button).

This could at least be a good workaround for downstream code right now, especially for determining behavior of pointer events based on the modifiers.

[almarklein]

Another related problem: Qt turns a button 1 into a button 2 when control is down on MacOS.