... just because there is no style context instantiated yet. Instead,
instantiate a style context during realize() and ask it.
Fixes problems with dim labels not being dimmed on first show.
Testcase included.
https://bugzilla.gnome.org/show_bug.cgi?id=735240
This is more for GTK developers to catch when they forgot to change
GTK_STATE_FLAGS_BITS after adding a new state flag than to prevent
widget developers from using the wrong flags.
gtk_widget_get_events() must indeed tell about events enabled purely through
a GtkEventController, those events will most surely trigger event handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=734357
Make gtk_widget_path_append_for_widget() add the state flags of the
widget, too.
This enables the ability to select pseudoclasses on all elements in a
selector.
The template documentation is lacking inlined examples on how to use the
templates API, like binding children and callbacks. This makes looking
for best practices a bit harder than it ought to be, for a feature this
useful.
This reverts commit b875572f2a.
Apps like Abiword, gnumeric and gnome-chess, and toolkits like
ClutterGTK were all using this for various purposes, and this made them
break. Bring back this feature for now.
It still won't work under Wayland.
gtk_widget_set_double_buffered is now deprecated, and we don't support
non-double-buffered widgets. This means that under normal circumstances,
paints are never outside of a begin_paint / end_paint sequence, which
natively-double-buffered backends like Wayland can't possibly support.
A few properties here are special, and can't benefit from it:
those which are just shorthands, like ::margin and ::expand,
and those that have explicit -set properties, like::hexpand
and ::vexpand.
Widgets becoming insensitive won't receive further events, but there
could be chances the controllers don't get properly notified and reset
in those situations.
The touch_event handler was missing those when emulating pointer events
for the widgets that get GDK_TOUCH_MASK set, but have no specialized
touch handlers.
This code is a product of early stages in the gestures branch, where
capturing would have an effect outside grab boundaries. But this isn't
really the case, so every gesture outside the grab scope must be reset
to avoid keeping stale data.
Before this change, a sequence being claimed deep in the event propagation
chain would make the sequence go denied on every ancestor, regardless of
previous state.
To make things more consistent, only deny the sequence if it was previously
claimed, so the behavior is the same for gesture groups within the widget
than for those outside the widget.
The gestures testsuite has been updated to reflect this new behavior.
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.
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.
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.
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.
Multiple calls are supposedly allowed to change the phase (although
unlikely to happen), so remove the g_return_if_fail() checking whether
the controller was already added.
Just call the controllers on that phase if the default widget handlers
are run.
For compatibility reasons, in the touch event handler, let the pointer
emulating touch be transformed to a pointer event as usual, in order to
have widget handlers a chance to run at all. If they have to be managed
by a controller in that phase, it'll have to be through the default pointer
event handlers.
This phase is meant to run in the default widget handlers, as opposed
to externally as in the bubble/capture phase. This will be most usually
the expected phase for every controller replacing code in event handlers
in GTK+, just so invocation and triggering order is kept unaltered.
We can end up with _gtk_widget_remove_controller getting called
while we are iterating over the list in _gtk_widget_run_controllers.
To avoid trouble, only mark the event controller as dead by
setting data->controller to NULL, and defer the actual freeing
and list manipulation to the loop in _gtk_widget_run_controllers.
Update other places that operate on controllers to handle
data->controller being NULL.
Make it really sure that the event is only emitted after every gesture
that consumed the button press is done with the sequence.
The event must only be emulated if a gesture in the capture phase happened
to consume the event, be cancelled, and
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,
