You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Linux, char and key down events are issued in that order, whereas Mac and Windows issue them as key down first and char second. This inconsistency causes bugs downstream, such as breaking egui-miniquad's copy and cut operations on Linux.
In other words, the char_event callback is called before the key_down_event callback. Meanwhile:
MacOS explicitly calls char_event followed by key_down_event
Windows will receive the WM_CHAR message before the WM_KEYDOWN message (based on MSDN docs), so it will also match the MacOS ordering
(I don't know about iOS and Android)
Impact
This inconsistency seems to be a cause of a bug in egui-miniquad for me: it is coded to ignore char events if the ctrl modifier is pressed, but the modifier state is only updated when the keydown event is received. So if I copy or cut some text on Linux, then the char event is received first and egui-miniquad has not yet recorded that ctrl is held down, which means that the char event is passed on to egui and the selection is replaced with x or c.
Obviously this could be fixed in egui-miniquad by also updating its modifier state in the char handler too (and this is how I am working around it currently), but if all platforms are able to emit keydown events before char events (i.e. we guarantee that ordering as part of the miniquad API) then that won't be necessary.
The text was updated successfully, but these errors were encountered:
Summary
On Linux, char and key down events are issued in that order, whereas Mac and Windows issue them as key down first and char second. This inconsistency causes bugs downstream, such as breaking egui-miniquad's copy and cut operations on Linux.
Details
Linux code looks like this currently:
In other words, the
char_event
callback is called before thekey_down_event
callback. Meanwhile:char_event
followed bykey_down_event
Impact
This inconsistency seems to be a cause of a bug in egui-miniquad for me: it is coded to ignore char events if the ctrl modifier is pressed, but the modifier state is only updated when the keydown event is received. So if I copy or cut some text on Linux, then the char event is received first and egui-miniquad has not yet recorded that ctrl is held down, which means that the char event is passed on to egui and the selection is replaced with
x
orc
.Obviously this could be fixed in egui-miniquad by also updating its modifier state in the char handler too (and this is how I am working around it currently), but if all platforms are able to emit keydown events before char events (i.e. we guarantee that ordering as part of the miniquad API) then that won't be necessary.
The text was updated successfully, but these errors were encountered: