If the widget isn't drawable anyway, just return;
If the widget needs an allocate, print a warning, since it indicates a
problem in the widget workflow (e.g. forgot to size_allocate a child
widget).
This maches the previous checks in gtk_widget_draw (with the same
problems).
When the GtkWidget hierarchy does not match the GdkWindow hierarchy, the
GtkWidget code may find a common ancestor that cannot be found while
traversing the GdkWindow tree using gdk_window_get_parent().
This happens with for example on Wayland, a GtkPopover has another
GtkPopover as parent, in this case, the GdkWindow parent is the root
window, whereas the GtkWidget parent is the other GtkPopover.
That confuses the gtk_widget_translate_coordinates() logic which will
bail out in this case and won't return the translated coordinates.
Make gdk_window_get_effective_parent() aware of subsurfaces and use the
transient_for which represents the actual parent (whereas the parent
might be pointing to the root window).
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=774148
For some reason, we are seeing damage being NULL here.
While that should never be the case, crashing on it is
unkind and makes the Wayland experience unusable.
The TextIter is passed by pointer for efficiency. We neither need to
modify it, nor should we leave it possible to accidentally do so. So,
it should be passed as a pointer-to-const.
We do not need to go through the heavyweight process of constructing a
TextLineDisplay just to get the direction out of it, when we can simply
use TextIter API to get the text and then get its direction using Pango.
Adapted from a patch by Mehdi Sadeghi for GtkSourceView:
https://bugzilla.gnome.org/show_bug.cgi?id=779081#c20
Add a documentation annotation saying that set_page_ranges transfers
ownership of the GtkPageRange array.
Add a g_free() call to fix a memory leak when set_page_ranges is
used repeatedly.
https://bugzilla.gnome.org/show_bug.cgi?id=780234
Since the later gtk_style_context_add_class doesn't care about the order
of the style classes, we can as well just prepend style classes to the
list and avoid the squared behavior when appending to a linked list.
Explain where the adjustment comes from, clarify some of the wording
about how its fields influence the scrollbar, and also note that the
steppers may not be present, since they aren’t in our default themes.
If the child added is not a Scrollable, it gets wrapped in a ViewPort –
which is. So it is impossible to end up with a non-Scrollable child.
Just check we have /any/ child where needed, which is semantically nicer
https://bugzilla.gnome.org/show_bug.cgi?id=778853
• intro: Clarify that external policy and/or adjustments can be used.
• add(): Don’t waffle on about having to add a ViewPort since we handle
that transparently for the user, so they can add() any widget.
• Adjustment stuff: most of this was repeating the docs for Scrollbar,
so just refer the user to that. Also, mention how
policies NEVER and EXTERNAL interact with all this.
https://bugzilla.gnome.org/show_bug.cgi?id=778853
has_tooltip_widget was assigned twice in immediate succession.
return_value is not used anywhere else in this function since commit
14a864c8b5 and does not need a default
value anymore, so move it to the inner scope and don't init to NULL.
hide_tooltip gets overriden in any case 2 lines down, and return_value
isn't used later in that function. The second assignment was introduced
in ef1da5f6c2, directly below the first
assignment.
