Previously we kept a Selector object for every "simple selector" (term
from CSS spec). Now we keep one for every match operation. So given the
selector
".a b:focus"
we will have 4 elements:
- pseudoclass ":focus"
- element "b"
- match any desendant (the space)
- class ".a"
Each of those is represented by a "selector class" which is basically
the collection of vfuncs for this selector.
If delta_x/y information is provided in scroll events, use it
to modify the underlying adjustment in steps proportional to
the deltas provided.
If the child widget of a scrolledwindow doesn't set
GDK_SMOOTH_SCROLL_MASK, regular scroll events will be dispatched,
and still handled by these 2 widgets.
If the touch sequence happens on a window with GDK_TOUCH_MASK set,
a GdkTouchGrabInfo is created to back it up. Else a device grab is
only created if the sequence emulates the pointer.
If both a device and a touch grab are present on a window, the later
of them both is obeyed, Any grab on the device happening after a
touch grab generates grab-broken on all the windows an implicit
touch grab was going on.
Touch events don't generate crossing events themselves, so
do not rely on these to determine whether the button release
happened within the event window.
This widget is too narrow to make touch interaction tricky enough, so
don't add the penalty of having the slider run farther from the touch
coordinates if it happens to miss the slider.
This is so submenus stay open as the parent menu item is
pressed/released, since the user would typically lift the
finger in order to select a submenu item.
This makes kinetic scrolling work with viewports where the
content does not otherwise select for button or touch events,
such as testscrolledwindow's label.
Kinetic scrolling is only done on touch devices, since it is
sort of meaningless on pointer devices, besides it implies
a different input event handling on child widgets that is
unnecessary there.
If the scrolling doesn't start after a long press, the scrolling is
cancelled and events are handled by child widgets normally.
When clicked again close to the previous button press location
(assuming it had ~0 movement), the scrolled window will allow
the child to handle the events immediately.
This is so the user doesn't have to wait to the press-and-hold
timeout in order to operate on the scrolledwindow child.
The innermost scrolled window always gets to capture the events, all
scrolled windows above it just let the event go through. Ideally
reaching a limit on the innermost scrolled window would propagate
the dragging up the hierarchy in order to keep following the touch
coords, although that'd involve rather evil hacks just to cater
for broken UIs.
This patch adds a capture phase to GTK+'s event propagation
model. Events are first propagated from the toplevel (or the
grab widget, if a grab is in place) down to the target widget
and then back up. The second phase is using the existing
::event signal, the new capture phase is using a private
API instead of a public signal for now.
This mechanism can be used in many places where we currently
have to prevent child widgets from getting events by putting
an input-only window over them. It will also be used to implement
kinetic scrolling in subsequent patches.
http://bugzilla.gnome.org/show_bug.cgi?id=641836
We automatically request more motion events in behalf of
the original widget if it listens to motion hints. So
the capturing widget doesn't need to handle such
implementation details.
We are not making event capture part of the public API for 3.4,
which is why there is no ::captured-event signal.
We don't want to fallback for 'random' touch sequences, since
that could lead to all kinds of pairedness and other violations.
Since the X server already tells us what touch events it would
have used for emulating pointer events, we just use that information
here.
GtkButton currently draws itself as active (pressed down) in case we're
pressing and holding the mouse pointer outside its bounds; this is
misleading though, since we won't activate the button unless the mouse
is released inside the button itself.
Fix this by only setting the ACTIVE state flag when the button is
actually pressed down.
https://bugzilla.gnome.org/show_bug.cgi?id=668141
This does nothing but turn all GtkBitmask functions into static inline
functions that call the gtk_allocated_bitmask_*() equivalent.
The implementation of the static functions has also been put into a
private header, to not scare people who want to see how things are
implemented.
When we're allocating children of GtkOverlay, compare their allocation
with the overlay one, and set left/right/top/bottom style classes if the
overlaid widget touches one or more of the overlay edges.
https://bugzilla.gnome.org/show_bug.cgi?id=669342
gtk_widget_translate_coordinates() can fail in case the widget is not
realized or there's no common ancestor. Don't use the x/y values
returned by that method in that case, since their value is undefined.
If there's a junction between the two scrollbars (i.e. they're both
visible), draw a background with a style class there, so the theme can
style it.
https://bugzilla.gnome.org/show_bug.cgi?id=669335
If the display server or GDK hides the window - fire the "deactivate" signal
to ensure that the internal state is consistent.
This patch also ensures that the "deactivate" signal will not be fired for a
menu that is not active.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=670881
Since GtkCellRendererText moved to WFH requests, our get_size
implementation is ignored. We should override get_preferred_width
instead. This fixes the accel renderer being clipped to a wrong size
when trying to edit its shortcut.
