Those used to work indirectly due to GtkEntry not setting GDK_TOUCH_MASK,
so pointer emulation would happen on those, but the event handlers on icons
and its icon-pressed/released signals have never been explicitly touch
aware, and this broke since the GDK_TOUCH_MASK can be set indirectly by
GtkGestures.
So make the icon event handler handle touch events, each icon can get hold
of one GdkEventSequence, reacting exclusively to it. This is still not
ported to GtkGesture due to GdkEvent exposure in these icon signals, as
users might expect GDK_2/3BUTTON_PRESS while GtkGesture ignores those.
Also, unset all icon pressed/sequence state on grab-notify, this used to
happen ad-hoc when initiating icon DnD, but that doesn't cut it for
user-defined reasons to initiate a grab (eg. popovers).
https://bugzilla.gnome.org/show_bug.cgi?id=736004
... in places where we draw a background. This was changed for GTK 3.0.0
to allow animations, but these days it doesn't make sense anymore to use
gtk_render_activity() for backgrounds.
GtkGestureSingle::button is set to 0 on the drag/multipress gestures, as several
buttons are managed by these gestures. Also, avoid some extra lines of code
setting what nowadays are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
This is expected to happen on wayland and other platforms with no primary selection,
and just leads to the selected text being cleared after any attempt to change the
text selection itself through either mouse/keyboard.
This changes the calculation of activity mode progress in the
same way as was done in GtkProgressBar a while ago, and make it
smooth, using a tick callback.
Instead of code that internally does weird things, use the FLAT style
class if has-frame is FALSE and remove it otherwise.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=732256
fixup entry
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.
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.
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.
Commit d05191a010 change the height
requisition to be completely dependent on the PangoLayout, but that
breaks when the font has special characters with different metrics.
Use the maximum between the two instead.
https://bugzilla.gnome.org/show_bug.cgi?id=728054
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
We don't want the size request to change as icons come and
go (thinking e.g. about the caps lock warning). Just make
sure that we have enough room for showing the icons.
This property is TRUE by default, when a popover is modal, it
will automatically set a GTK+ grab on the popover, and grab
the keyboard focus into the popover.
