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.
This reftest makes use of the new feature to add signal handlers.
It adds a libreftest.so module containing all the code for the reftests.
When adding a test named reftest.ui, please keep code contained in a
source file names reftest.c and add that file to Makefile.am.
https://bugzilla.gnome.org/show_bug.cgi?id=730833
When connecting signal names, gtk-reftest now allows you to use a colon
in the signal handler name like so:
module:function_name
where module is a module loaded from the same directory (or the .libs
subdirectory for compatibility with uninstalled libtool) as the running
test and the function is resolved in that module. Of course, normal
function names work as before.
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.
