When full-draw is set, use the `rect` passed as argument
to `drawRect` and ignore `drawn_rects` invalidation.
This may fix some missing redraws when switching tabs.
Properly special case first single touch; fall
back to allow windows to emulate mouse events for it.
Yet let gdk handle any multi-touch events, not allowing gestures.
* Fix special case of first single touch. While another touch
is active, any new touch must not get the ID of the (ignored)
first touch.
* reset "last-touch" coordinate on touch-begin.
Previously it was possible that the first motion event was
ignored.
NB: This does not fix missing events when the first touch
coincides with any other finger (gesture?).
Found via `codespell -q 3 -S "*.pdf,*.po,./.git,*.tosc,./waf,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch" -L acount,addin,ane,ba,buss,busses,caf,capela,devine,disconnectin,discreet,doubleclick,envolution,filetest,fo,ghandi,homs,hsi,layed,maschine,mis,nd,ontop,pass-thru,removeable,retrn,ro,scrollin,sectionin,seh,siz,sord,sur,te,trough,ue,wth`
Gestures may prevent a 2nd touch from being registered as
such (and instead report a zoom/pinch gesture).
At least that is my best guess, why Nathan needs 3 fingers
to move 2 Faders :)
Popup Dialog Windows never unset the modal flag.
e.g. Session > Save Snapshot & switch.
Furthermore a 2nd dialog was able to get the menu stuck
forever (e.g. Snapshot & Switch .. -> Replace existing?
In order for the Filechooser Location widget to work two
things need to be setup, which only the FileChooserDialog
does:
* subscribe to Widget's "response-requested" signal
* call should_respond () hook from top-level window's
default handler.
The Location Entry emits "activates-default". In case of
the Dialog, that calls the dialogs response callback,
which then calls ` _gtk_file_chooser_embed_should_respond`.
That handles changes made by the user to the location entry.
-=-
Gtk::FileChooserWidget does not handle this, "response-requested"
signal is not exposed, nor is _gtk_file_chooser_embed_should_respond
available outside Gtk.
This change at least selects the file in the treeview, which
allows further handling, without interfering with FileChooserDialog's
behavior.
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).
On macOS popping up a menu with a position function that leads the menu to be
under the mouse pointer generates the same initial set of enter events as on
linux, but this is then followed by some leave events and then a repeat of the
same set of enter events.
this exposes what appears to be a logic error in gtk_menu_enter_notify().
Nonlinear enter events (i.e. where the menu pops up under the mouse, so the
mouse was never actually moved into the menu's window) should not cause a reset
of priv->seen_item_enter. This value, when true, is used to force the next
received button release event to be handle as an menu activation event. This
should only happen when the mouse has actually been moved by the user into the
menu (as already indicated in existing comments). The value has this effect by,
on the next enter event for a menu item, if already set, forcing
menu->activate_time to zero, which in turn will cause menu activation on button
up/release.
This bug doesn't appear on Linux (or Windows) because the event sequence
associated with a menu popup is different. The lack of another set of enter
events means that menu->activate_time is never reset, and so the behavior is as
expected.
This change makes the setting of priv->seen_item_enter be idempotent with
respect to non-linear enter events, which I believe is the intended behavior.
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.
