Without this, kitty fails to compile:
```
glfw/cocoa_init.m:462:14: error: case value not in enumerated type
'NSEventModifierFlags' (aka 'enum NSEventModifierFlags')
[-Werror,-Wswitch]
case (NSEventModifierFlagShift | NSEventModifierFlagOption):
^
glfw/cocoa_init.m:465:14: error: case value not in enumerated type
'NSEventModifierFlags' (aka 'enum NSEventModifierFlags')
[-Werror,-Wswitch]
case (NSEventModifierFlagShift | NSEventModifierFlagCommand):
^
```
I thought about changing the type of the `modifierFlags` function parameter from `NSEventModifierFlags` to `NSUInteger` since `NSEventModifierFlags` is defined as an enum according to https://developer.apple.com/documentation/appkit/nseventmodifierflags?language=objc and is technically not the proper type for a bit field. But since Apple themselves define `modifierFlags` as `NSEventModifierFlags` according to https://developer.apple.com/documentation/appkit/nsevent/1534405-modifierflags?language=objc, I think the fix in this commit is better.
This warning was introduced with commit f9944e6140.
This piece of code is not run when the `GLFW_COCOA_MENUBAR` init hint is set to `0`, which kitty does.
This reduces the difference to GLFW upstream a little.
GLFW creates the menu bar in the applicationWillFinishLaunching method, while kitty creates it in `create_os_window()`. This patch changes the behaviour to match GLFW.
In practice, without this change, there can be a short time where the menu bar is not fully populated.
The time is stored in a signed 64 bit integer with nanosecond accuracy. This eliminates the possibility of floating-point inaccuracies.
`monotonic_t` can currently hold values large enough to work correctly for more than 200 years into the future.
Using a typedef instead of directly using `int64_t` everywhere will also allow easily changing the datatype in the future should the need arise for more precise or bigger time values.
Also reduce input latency by ignoring repaint_delay when
there is actual pending input.
Gets rid of request_tick_callback(). Now empty events
result in the tick callback being called so there is only a
single mechanism for waking up the main loop and getting
the tick callback called.
I had added an optimization to not pass messages to
main thread every time the CVDisplayLink timer fired, unless
a render frame for that monitor was actually requested.
However, this optimization is impossible to implement wihtout a deadlock
since CVDisplayLink has its own internal lock that it does not expose.
So I guess macOS users with multiple monitors will simply have to take
the performance hit of useless wakeups sixty times a second for every
extra monitor.
Fixes#1779
performSelectorOnMainThread runs in more loop run modes which means that
the tick callback will behave more like it does on other platforms,
during window resizes and other modal event loops.
pagedown
Kovid Goyal
Luflosi
Benoit de Chezelles