This works around an issue with some embedded plugin windows not being
properly restored when the window is restored after being minimized. It
also prevents zooming (full-screen) display of dialog windows.
Also recent macOS allows to maximize Windows even if they are not
supposed to be resizable (also causing issues with some plugins).
YDK2 uses SetSystemUIMode() for fullscreen. This also uses space
otherwise reserved for the menu bar at the top, and is apparently
preferable for Ardour's UI.
However when a user manually enters fullscreen using the window
title-bar's green button (NSWindow toggleFullScreen). YDK will crash
when the user then also tries to use YDK's fullscreen mode:
```
NSWindowStyleMaskFullScreen cleared on a window outside of a full screen transition.
called from
[NSWindow setStyleMask:]
gdk_window_set_decorations
gdk_window_fullscreen
```
Ideally we'd set NSApp presentation flags so that the toplevel window
would allow one to zoom (maximize), but not to enter fullscreen. Like it
used to be on OSX. It is unclear how to achieve this on macOS for
resizable windows, short of marking the top-level window a dialog or
utility window.
macOS has broken its exposure/redraw model at least twice by always providing the entire area
of an NSView for every call to drawRect, and cannot provide the list of rects. This change
expands the tracking done using the needs_display_region, and does so directly via the
objective C methods of an NSView (and its derived children like GdkQuartzView).
The result is that when we send an expose signal, GDK/GTK code can obtain an accurate
list of the invalidated rects if desired, and thus avoiding redrawing the entire contents
of a window
recent gcc (>=11) sets _WIN32_WINNT >= 0x602 which changes
QS_ALLINPUT to include (QS_TOUCH | QS_POINTER) events which are
only available on Windows 8 and later. Listening to those events
makes ardour unresponsive.
