GtkBuildable's get_name()/set_name() methods may shadow
GtkWidget's methods. Avoid that by renaming the API to
get_buildable_id()/set_buildable_id(), which also reflects
the name of the XML attribute the API refers to.
https://gitlab.gnome.org/GNOME/gtk/-/issues/3191
The iter may be invalid, so we may not read from it.
testsuite/gtk/treemodel tests this and valgrind is shouting about it,
but it never crashed until I just ran it...
This bug is from 2004 and the test is from 2007. I guess invalid memory
accesses don't get caught by CI much.
The previous type was a pointer to a pointer, which seems to be a copy-paste
error from GtkBuildable.custom_tag_start which is an out parameter. It was
always cast in use so this is an API break, but not an ABI one.
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
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.
Pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=699016
The fix here is slightly different. We make
_gtk_builder_parser_translate return a const char * instead of
a dup'ed string, and fix up the callers.
Both GtkListStore and GtkTreeStore had a few methods that allowed
-1 to mean 'append' when specified as a position, but others that
demanded positive position arguments. Make this consistent by
always allowing -1.
https://bugzilla.gnome.org/show_bug.cgi?id=667808
Mark the new_order argument as zero-terminated array, even though it does not
need to be zero terminated (it has an implicit length not given by a constant
or another method argument). It does not hurt if bindings append an extra zero
to the array as long as it has enough elements, and this makes the method
introspectable.
https://bugzilla.gnome.org/show_bug.cgi?id=677941
There are three bugs here:
- we should check if the value type is transformable instead of being
compatible, since that's all we care about in order to call
g_value_transform()
- the check is only meaningful in the direction
passed-in-type->column-type and not viceversa
- we should init the destination GValue to the column type before
calling g_value_transform on it, or the destination type information
will be missing and the method will fail
Thanks to Jasper St. Pierre and Colin Walters for all the help in
tracking this down.
https://bugzilla.gnome.org/show_bug.cgi?id=677649
