If gtk_builder_expose_object() is called twice with the same name, it will
result in a g_critical(). This improves that situation by checking for the
object before exposing additional times.
This turns out to be handy in situations where templates are expanded
multiple times, such as application-side implementations of UI merging.
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
We were only applying <binding> elements when the
object is constructed, which can be triggered by
various things (e.g. a <style> element). Defer
this until we reach </object>, so we can be sure
that we pick up all the bindings.
Testcase included.
Fixes: #4147
The GtkBuilder parser constructs the object e.g.
when handling a <binding> element. There may be
more <property> elements after it, which we were
just not applying. Fix that by always applying
property when we see </object>. To do that, we
need to track the applied status per property.
Test included.
Fixes: #4208
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.
In GTK 3, it was pretty much always better to use
gtk_builder_new_from_whatever() rather than
gtk_builder_add_from_whatever(). But in GTK 4, this is no longer
generally true. Let's add some context on when you want to use one or
the other.
With the exception of gtk_buildable_get_id(), those are only used
to construct objects from XML descriptions, which is functionality
internal to GTK.
The API is therefore unlikely to be missed, and keeping it internal
means they can no longer unintentionally shadow object methods in
bindings with less namespacing; for example it's currently ambiguous
whether `infoBar.add_child()` refers to gtk_info_bar_add_child() or
gtk_buildable_add_child().
https://gitlab.gnome.org/GNOME/gtk/-/issues/3191
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
Use GTK_DEBUG=builder-objects to make GtkBuilder warn
if a named object from a ui files doesn't get claimed
by gtk_builder_get_object(). This is useful for finding
dead wood in .ui files.
Since it's a type with sub-classes, we need to use GTypeInstance (at the
very least), otherwise we won't be able to address each sub-class as
such.
This is similar to how GskRenderNode and GdkEvent are handled, with the
added difficulty that GtkExpression is meant to be used in properties,
in order to be deserialised by GtkBuilder. This requires adding a
GParamSpec sub-class that we can match on from within GtkBuilder,
alongside some convenience API for storing a GtkExpression inside a
GValue.
