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).
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.
If you set GTK_INSPECTOR_RENDERER to the same type of
values that GSK_RENDERER takes this can change the renderer
used for the inspector. This is useful if you're debugging
one renderer and don't want to affect the inspector.
We can e.g. get the entry dispose()d and a focus_out event after that
(because the toplevel unsets the focus which previously was the entry).
We then later use priv->current_pos in a call to pango API which makes
sure the given index is valid for the given layout. Since we lazily
create a GtkEntryBuffer in get_buffer() and a PangoLayout lazily in
gtk_entry_create_layout, these 2 are always valid but don't match
priv->current_pos in this situation.
Fix this by resetting priv->current-pos in dispose().
