Previously, there would be globally just a capture and a bubble phase,
with the event just going down the hierarchy once, and the up once.
GTK_PHASE_TARGET actually meaning "run within event handlers", so in
a hierarchy of 3 widgets, emission would be:
Capture(C)
Capture(B)
Capture(A)
Target(A) (if event handlers allow)
Bubble(A)
Target(B) (if event handlers allow)
Bubble(B)
Target(C) (if event handlers allow)
Bubble(C)
This commit changes this behavior and uses GTK_PHASE_TARGET in a less
misleading way, running only on the widget that was meant to receive
the event. And GTK_PHASE_BUBBLE has taken over the execution place of
GTK_PHASE_TARGET, so the emission remains:
Capture(C)
Capture(B)
Capture(A)
Target(A)
Bubble(A) (if event handlers allow)
Bubble(B) (...)
Bubble(C) (...)
As it was, GTK_PHASE_BUBBLE was useful for running event controllers
paralelly to event handlers, without modifying a single line in those.
For those mixed scenarios, Any of the other phases will have to be
used at discretion, or the event handlers eventually changed to chain
up and let the default event handlers in GtkWidget to be run.
The events to those are fed outside the regular event propagation scheme,
through _gtk_window_check_handle_wm_event(), so set the controller to
GTK_PHASE_NONE so events aren't processed first manually, and then
automatically.
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
Go back to respecting GtkMisc::xpad/ypad. Not doing so breaks
the misc-alignment reftest. As long as we still derive from
GtkMisc, we may as well do this.
The icontheme lookup code has a special-case that prefers builtin icons
if the theme name is "hicolor". This is problematic for our reftests,
which run in a barebones environment with not settings.
Drop the ref on the action muxer in finalize, and also make sure
shutdown() tears down the muxer setup done in startup().
When GtkApplication adds itself to a muxer, it causes the muxer to take
a ref on the GtkApplication. This has to be undone in shutdown() to make
sure the GtkApplication doesn't end up holding a ref on itself.
https://bugzilla.gnome.org/show_bug.cgi?id=730383
And handle the fact that drawing bounds are now handled by this API and
the corresponding gtk_widget_get_clip().
Also add _gtk_widget_supports_clip() function to check if a widget has
been ported to the new world.
Now that labels and images no longer use x/yalign in their code,
we need to make gtk_misc_set_alignment set the h/valign for these
widgets, to keep it stumbling along until its final demise.
https://bugzilla.gnome.org/show_bug.cgi?id=730613
Those get in the middle more than help on these widgets, the widget
is already packed with clickable areas and having handles (and their
invisible clickable area around) hovering above don't help, plus the
purpose in most likely numeric values is a bit doubtful.
All touch events are either consumed by the up/down panels, or
the swipe gesture, all GtkEntry handling of touch events on the text
window is avoided, so handles to not appear anymore.
the "bubble" phase used to run before event handlers before GTK_PHASE_TARGET
was added, in order to keep phases in the expected order, move GTK_PHASE_BUBBLE
to be run (still invariably) after event handlers.
The only behavioral change should be wrt widgets wanting mixed event handler/
gesture handling, they could previously attach the gesture to the bubble phase
and check for gtk_gesture_is_active() in the event handler to bail out, they'll
have to use GTK_PHASE_CAPTURE for that purpose from now on.
The handle is still centered horizontally, but the extra vertical
space wasn't taken into account, leading to misplacing the dragging
point (and the handle) during motion events.
