This does not match X11/macOS behavior. And I see no logical reason why
it should be so. The wheel_scroll_multiplier should be used to adjust
this by end users.
On compositors that support compositor key repeat events, use those, for
complete robustness. Sadly no actual compositor implements these yet.
Otherwise use a timer fd/pipe to queue the repeat events and only
dispatch them after events from the compositor are handled. This means
release events from the compositor will prevent spurious repeat events.
One can, in the worst case lose some repeat events if there is a very
large interval between the start of the timer and the next poll, but
that is unavoidable and is why repeat events should come from the compositor
in the first place.
Fixes#9224
Far more robust. Sadly no actual compositors yet support this. Fifteen
years it takes Wayland developers to correct their most basic mistakes.
See #9224
The locks were not being initialized, and since I was there did some
general cleanup as well, moved the locks array into displayLinks rather
than having another global namespaced variable.
Apparently on some systems Tahoe sends a resize event on wake from
sleep/lid open for obscure reasons and then proceeds to crash if one
redraws during that event. Sigh.
This is nicer now every OS Windows doesnt cause a notification. Also
fixes#9034 which was caused by us setting an explicit appearance on the
window when the titlebar is set to a specific color thereby preventing
the views in the window from getting appearance change notifications.
There were two issues.
1) Setting window background color to a non-zero opacity causes
darkening (essentially there were two layers of blending)
2) The titlebar background view could end up in the wrong position
because it was a child of the content view rather than its super view
Fix both issues setting the window background to clear color and
moving the background view into the super view while making sure it is
positioned correctly using explicit constraints. Phew.
