GTK+ 2.x only looked up action *names* and ignored the namespacing offered by
action groups. This means that if there are two actions in different groups
with the same name, GtkUIManager may not find the one intended when it is
referenced in a menus definition file.
This commit changes that - if the action name contains a '/' character it is
assumed to contain both the action group name and the action name, and it will
only look for the action within the named group.
_gdk_window_process_updates_recurse() may recurse (duh),
and reenter drawRect. So `needs_display_region` needs
to be unset immediately, not at the end of the method.
extern here is literally C `extern`, not DLL exported functions,
see libs/tk/ztk/ztk/atkversion.h
```
#ifndef _ATK_EXTERN
#define _ATK_EXTERN extern
#endif
```
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.
