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.
This one is a little tricky, since we override this property
in many places, and you cannot add flags when overriding. So,
all places where this is overridden will have to make sure to
notify explicitly.
When we expanded the GtkLicense enumeration in 3.12, we forgot
to update the limit check in gtk_about_dialog_set_license_type.
Caught by testing property notification for enum properties.
We were applying response based heuristics, even if the button
is explicitly put in the headerbar. That broke button placement
in some epiphany dialogs, such as the Cookies one. Therefore,
restrict the heuristics to action widgets that are added through
gtk_widget_add_action_widget() or <child type="action">, where it
is not possible to specify placement explicitly.
When combining action child type with <action-widgets> to assign
response ids, we were not properly updating buttons that ended up
getting added to the headerbar before they have a response id.
Fix this by reapplying the headerbar button setup after parsing
<action-widgets>, and make sure to also update the suggested-action
style class.
If called when already popped down, warnings would be issued due
to priv->grab_pointer being unexpectedly NULL, this would happen
in regular operation when selecting items in appears-as-list mode.
So both add a NULL check for priv->grab_pointer, and bail out early
if the popup window is already hidden.
GtkKineticScrolling implements the actual physics laws for friction
and springs. When created, position/velocity/boundaries/constants are
given, so at every gtk_kinetic_scrolling_tick() it returns the current
position, and whether the system is in rest.
https://bugzilla.gnome.org/show_bug.cgi?id=729608
A multipress gesture takes care of link handling, and char/word/all
selection mode on selectable labels. A drag gesture is used for both
text selection and DnD checks on selectable labels.
A multipress gesture takes care of clicks, and where those happened.
If the click is meant to move the slider while pressed, the drag gesture
takes over, dragging the slider while active.
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 signal handler for the visibility of menu items changing had the
wrong signature, resulting in the GParamSpec from the notify signal
being treated as a boolean (which was always true). This resulted in
items being added over and over and never being removed.
Fix that...
Since commit 872fbfac the GtkWindowGroup was split out from the GtkWindow
sources, so include gtkwindowgroup.h to avoid C4013 warnings/errors
(implicit declaration of ...) on gtk_window_group_add_window().
We were setting the next-tab properly, but were trying to
read it off the wrong object. Now, going from a cell renderer
attribute mapping to the model, or from an action-name to the
action actually works.
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.
It might happen that a gesture claims a sequence before any other gesture
in its group even handled a single event from that sequence. In that case,
ensure the state is set accordingly right when the sequence is handled in
those.
The "group" gesture testcase has been updated to observe this behavior.
The CSS editor was feeling a little sluggish, because it was
reparsing and reapplying the CSS on every keystroke. Add a small
delay, to make this feel smoother.
Like the GDK and GTK portions, use autotools scripts to generate the
complete projects for gtk-inspector as sources there seem to change from
time to time.
It might be so that this, like the a11y sources, will be referenced from
the main Makefile.am of GTK directly, but just do this so that the
projects can build properly.
Every button press/release event reaching the the multipress gesture in GtkWindow
and happening in the "title" region must be handled, regardless of the event widget.
Children there wanting the event(s) for themselves are (and were always) expected
to stop event propagation.
So the only place to check for the event widget's "window-dragging" style property
is the "content" region, which matches the pre-gestures behavior.
This fixes some issues with sequences being mistakenly claimed (and events not
propagated further) on situations it shouldn't.
The multipress gesture must react to either direct events on the
GtkWindow (special cased through _gtk_widget_check_handle_wm_event),
or bubbled events from child widgets. Ensure bubbled events go
through the gesture, those are fed manually to make sure events are
only handled once, in either one or other place. The implicit grab
will ensure that doesn't change mid-action.
Otherwise the event is possibly handled, but still propagated further anyway.
Ensure the event is consumed by claiming the current sequence on the
GtkGestureMultiPress::pressed handler.
::row-activated only used to be triggered by GDK_BUTTON_PRIMARY, so make
the multipress gesture handling this now to be only triggered by that same
button.
https://bugzilla.gnome.org/show_bug.cgi?id=731020
This gesture was only meant to react on GDK_BUTTON_PRIMARY (either
through real pointer events, or implicitly assumed from touch events),
as it used to behave before gestures. Otherwise the gtk_drag_begin*()
call assumes being triggered by button 1, and the drag misbehaves
because that button isn't really in the state mask.
https://bugzilla.gnome.org/show_bug.cgi?id=731016
When going from attribute mapping to model, it makes most sense
to go directly to the data tab, and when going from an action
name to the owner, we want to show the actions tab. Make it so.
The extra condition here that caused the current child to
not redraw during reordering was introduced in f383e1f1
during the port to ::draw, but was not explained in the
commit message, and removing it has no obvious negative
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=730767
Just calling get_type() does not ensure that the signals, properties
and everything else gets set up properly. Ensure it is, by calling
g_type_class_ref() before using the type. This fixes the testcase
added in the previous commit.
Those might trigger the destruction of some widget that would dispose the
event controller while the event is still being handled, so keep an extra
ref on the controller during event processing.
Without this information introspection-based consumers don't realize
they can include context information, but instead think that they
receive an extra gpointer argument (which they don't know how to
handle).
https://bugzilla.gnome.org/show_bug.cgi?id=730745
This will hopefully help resolve the circular dependency between
libgtk linking against inspector/libgtkinspector and inspector/
needing extract-strings from gtk/.
I didn't preserve the EXEEXT decorations in this operation -
automake gave me stern warnings about it, so I just dropped them
all. Somebody who cross-builds GTK+ will have to reconstruct this.
This prevents some of our generic object implementation tests
from working with gesture objects. Instead, add g_return_if_fail
checks in all the gesture constructors.
Mainly doing s/TARGET/BUBBLE/ on the fully ported widgets, but GtkTreeView
where the double click handler has moved to GTK_PHASE_TARGET so it runs
parallelly to the still existing event handlers.
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.
GtkPaned may just capture pointer events because the child widget
doesn't happen to have GDK_TOUCH_MASK set, resort to checking the
device in that case.
Dragging is all handled by a GtkGesturePan now, matching the
paned orientation.
On touch events, a wider area is listened for, so touch events
don't need to be as accurate to initiate dragging, if no dragging
is truly initiated in this case, events are just forwarded for
child widgets to handle.
A pan gesture is used to handle switch dragging, which is only triggered
by horizontal panning movements. A multipress gesture handles the cases
where clicking without dragging happens, just toggling the switch.
A pan gesture is optionally attached if there is only one scrolling direction, the pan
gesture orientation is changed so movements tangential to the scroll direction get
scrolling cancelled (The pan gesture is automatically denied when that happens, and
that state change spreads to the others gestures in the group). If the pan direction
happens in the expected directions, no cancellation happens, and scrolling eventually
takes place.
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.
Presses alternatively show and dismiss the popover, the popover is still
always shown invariably after any dragging happens (either text selection,
or dragging a text handle)
Presses alternatively show and dismiss the popover, the popover is still
always shown invariably after any dragging happens (either text selection,
or dragging a text handle)
Similarly to GtkTextView, a GtkGestureMultiPress gesture handles
button/touch presses to initiate one selection mode or other, and
a GtkGestureDrag is used to handle text selection and DnD checks.
The code from button press/release, motion, and grab_notify handlers
has been shuffled into the actions triggered by those gestures.
A GtkGestureDrag is used for color selection, removing also the
need to track the pointer state in widget data. The GDK grab performed
just to set the crosshair cursor has been replaced by a call
to gdk_window_set_device_cursor(), which will be unset if the
drag operation is finished, or cancelled due to the implicit grab
being broken.
All "exclusive" gestures listen for either pointer events, or
"pointer emulating" touch events, so only a single sequence at
a time can make these run.
This signal will always be paired with a ::pressed signal, unless
the sequence is cancelled, or the controller is reset. the n_press
argument in the signal always matches the ::press signal one, even
if GtkGestureMultiPress::stopped was emitted in between.
The current sequence (as per gtk_gesture_single_get_current_sequence)
is used to find out the coordinates. And only emit ::pressed if the
gesture began through a GDK_BUTTON_PRESS/TOUCH_BEGIN (eg. not due to
an extra touch being lifted)
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.
That may happen separately from grab-notify, and also due to external
reasons, so ensure all sequences are cancelled if a grab is taken
in some GdkWindows that would obscure events on the controller.
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
Sequences may be cancelled within the ::sequence-state-changed handler, which
would change the points hashtable as it's being iterated in this function. So
iterate over a list of sequences and let the hashtable change freely.
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.
