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.
- 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.
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:
⌘ -> metaandcontrol -> controlandoption -> alt.⌘ -> controlandcontrol -> meta.metakey 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:
modifiers, so 'primary' in the list together with 'Control' or 'Meta'.modifiers2field that has 'higher level' modifiers, where the key that 'primary' replaces is not present.primary_downfield to the event object.shift_downthen too, for consistency.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.