The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
Within a widget, if a gesture accepts a sequence, it would previously
cancel every other gesture that not in the same group. Change this to
only cancelling gestures that previously claimed the gesture, and let
gestures with state=NONE for that sequence remain like that.
This enables late recognition of gestures, even on the presence of
another gesture group that was more eager at claiming the gesture.
One usecase is user-defined panning gestures on scrolledwindows,
if ::capture-button-press is TRUE (eg. the default), the gesture is
claimed early in order to consume the button press, but that would
tipically make every other gesture group deny the sequence. With
this change, the pan gesture can keep state=NONE, and later claim
the sequence for itself if the panning gesture is recognized.
Also, do not propagate state=DENIED to every gesture in the widget,
that was unintended.
The utility of those signals is somewhat dubious now that there is
gtk_gesture_group(), so make that the only way to coordinate gestures.
The cooperation model offered by gtk_gesture_group() is flexible
enough,
Listen for notify::sequence-state-changed on the controller, so the
only way to manipulate a sequence state are gtk_gesture_set_sequence_state()
and gtk_gesture_set_state().
Also, make use of gesture groups, so the sequence state is set at once
on all gestures pertaining to a single group. Within a widget, if a sequence
is claimed on one group, it is made to be denied on every other group.
GtkEventController may be certainly useful to keep event
handling self-contained in other places than gestures, but
the current widget API is highly related to gestures, so
just using GtkGesture as the argument there will be quite
more convenient. The other places where GtkEventController
make sense as a base object will better provide their own
hooks.
Gestures attached with this phase will expect callers to have it
receive events through gtk_event_controller_handle_event(), but
the gesture will still be notified of sequence state changes,
grabs, etc...
If the captured touch begin or button press event have been consumed
for the given sequence, propagate it upwards if the sequence goes from
claimed to denied, so the widgets on the way to the event widget receive
a coherent event stream now that they're going to receive events.
The policy of sequence states has been made tighter on GtkGesture,
so gestures can never return to a "none" state, nor get out of a
"denied" state, a "claimed" sequence can go "denied" though.
The helper API at the widget level will first emit
GtkWidget::sequence-state-changed on the called widget, and then
notify through the same signal to every other widget in the captured
event chain. So the effect of that signal is twofold, on one hand
it lets the original widget set the state on its attached controllers,
and on the other hand it lets the other widgets freely adapt to the
sequence state changing elsewhere in the event widget chain.
By default, that signal updates every controller on the first usecase,
and propagates the default gesture policy to every other widget in the
chain on the second. This means that, by default:
1) Sequences start out on the "none" state, and get propagated through
all the event widget chain.
2) If a widget in the chain denies the sequence, all other widgets are
unaffected.
3) If a widget in the chain claims the sequence, then:
3.1) Every widget below the claiming widget (ie. towards the event widget)
will get the sequence cancelled.
3.2) Every widget above the claiming widget that had the sequence as "none"
will remain as such, if it was claimed it will go denied, but that should
rarely happen.
This behavior can be tweaked through the GtkWidget::sequence-state-changed and
GtkGesture::event-handled vmethods, although this should be very rarely done.
A controller can be optionally hooked on the capture or the bubble
phase, so the controller will automatically receive and handle events
as they arrive without further interaction.
Make the relative_to widget the parent for a GtkPopover's
GtkActionGroup. This, for example, makes the menu model of a
GtkMenuButton find action groups attached to the button.
https://bugzilla.gnome.org/show_bug.cgi?id=729915
The documentation for the GtkWidget::size-allocate signal is missing the
description of the "allocation" parameter. Add the missing description
to the parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=726179
Add gdk_device_get_last_event_window(), and use to implement the window
tracking we need for synthesizing crossing events for sensitivity changes
and gtk grabs, rather than keeping the information in qdata and updating
it based when GTK+ gets events.
https://bugzilla.gnome.org/show_bug.cgi?id=726187
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
The properties are declared read-write, but only the setter
was hooked up. This was leading to criticals in test apps using
the prop-editor.c code. Complete the implementation by adding the
getter side too.
