In many cases, we have an "extra-menu" property that is used to allow
applications to join menus into the native menu for the widget. Previously,
this was done by nesting that menu in a section.
Doing so increases the complexity of the rules for GtkMenuTracker as you
may want different handling from inside of the section vs toplevel
sections.
If instead we synthetically glue the menus together, we have a much more
natural joining of menus as the application developer would expect for
their menu.
This also ports GtkLabel, GtkText, GtkPasswordEntry, and GtkTextView to
use the joined menu helper.
The joined menu helper comes originally from GNOME Builder and has had
extensive use there.
Fixes#4094
This allows developers to modify the pango context that is used when
rendering text within the text view.
Such access can be useful to alter how rounding occurs with API such as
pango_context_set_round_glyph_positions() and is needed by GtkSourceView
for proper placement of glyphs within the overview map.
Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
Stash away the device timestamp when obscuring
the pointer, and compare it when we decice whether
to unobscure it. This fixes a problem where synthetic
motion events would make the cursor reappear
prematurely.
Fixes: #3792
If multiple nested widgets have drag sources on them, both using bubble
phase, we need to reliably pick the inner one. Both of them will try to
start dragging, and we need to make sure there are no situations where the
outer widget starts drag earlier and cancels the inner one.
Currently, this can easily happen via integer rounding: start and current
coordinates passed into gtk_drag_check_threshold() are initially doubles
(other than in GtkNotebook and GtkIconView), and are casted to ints. Then
those rounded values are used to calculate deltas to compare to the drag
threshold, losing quite a lot of precision along the way, and often
resulting in the outer widget getting larger deltas.
To avoid it, just don't round it. Introduce a variant of the function that
operates on doubles: gtk_drag_check_threshold_double() and use it instead
of the original everywhere.
Check the text handle role, instead of looking for the other handle
visibility. The other handle may be invisible during selection mode
(e.g. pointing to offscreen contents). This fixes both this code
switching to cursor mode out of the blue, and possible crashes later
on as this handle might be hidden in the process, while its own event
controller is handling events on the parent surface.
The gtk_text_view_set_handle_position() function called some lines above
takes care of handle visibility already, also accounting for other
conditions (e.g. whether the handle points to contents onscreen).
Forcibly showing handles here misbehaves if the handle should stay hidden,
and somewhat expensively as it involves creating and throwing a native
surface every time.
With the scrolledwindow drag gesture not claiming the sequence immediately,
we end up placing the cursor (and undoing the previous selection) each time
we scroll.
There is already handling too short drags in ::drag-end, so let this code
handle touchscreens as well.
If the gesture becomes captured (e.g. from a parent scrolledwindow), we
leave some things in the air. Clean these up properly. This is recurrent
with touch scroll.
When we start a dnd of the selection in the drag-update handler,
set the gesture state to denied. Otherwise, we get more drag-update
signals, and things get really confused, leading to no dnd and
sadness.
