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.
There are plans to add session-dependent defaults to GSettings
(based on the newly standardized XDG_CURRENT_DESKTOP); until
then, the WM uses a different schema for its button-layout
setting in classic mode. So for the time being, do the same
and pick the alternative schema when XDG_CURRENT_DESKTOP
indicates that we are in a classic session.
(It's not pretty, but hopefully won't be with us for too long ...)
https://bugzilla.gnome.org/show_bug.cgi?id=731273
Pick up the setting from the org.gnome.desktop.wm.preferences schema
if available. It is slightly more involved than other settings, as
the actual button names used in the schema differ from the ones we
use, so we need an additional translation step.
https://bugzilla.gnome.org/show_bug.cgi?id=731273
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.
This tests both a sequence being claimed early to be then denied
(and handled deeper in propagation chain), and a sequence being
claimed late in the capture phase (and thus being cancelled deeper
in the propagation chain)
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.
