Most users were just forgetting to set the proper flags.
And flags aren't the right way to set this anyway, it was just
acceptable as a workaround during GTK3 to not break API.
The API encouraged wrong usage - most of the users were indeed wrong.
Use the correct version instead:
gtk_icon_theme_get_for_display (gtk_widget_get_display ())
This name can show up in error messages or profiler
traces, so it is nice to provide some hint what
file we are dealing with.
<GtkFileChoser template> is a lot more helpful
than <input>.
GtkBuilderScope is an interface that provides the scope that a builder
instance operates in.
It creates closures and resolves types. Language bindings are meant to
use this interface to customize the behavior of builder files, in
particular when instantiating templates.
A default implementation for C is provided via GtkBuilderCScope (to keep
with the awkward naming that glib uses for closures). It is derivable on
purpose so that languages or extensions that extend C can use it.
The reftest code in fact does derive GtkBuilderCScope for its own scope
implementation that implements looking up symbols in modules.
gtk-widget-factory was updated to use the new GtkBuilderCScope to add
its custom callback symbols.
So it does it different from gtk-demo, which uses the normal way of
exporting symbols for dlsym() and thereby makes the 2 demos test the 2
ways GtkBuilder uses for looking up symbols.
Use it as the default object for expression binds and when connecting
signals. It is intended to work kind of as the "this" object while
parsing. In fact, the term "current object" was stolen from the Java
docs and various C++ tutorials for the this pointer.
Set the current object in gtk_widget_init_template() and
GtkListItemBuilder.
This more-or-less replaces the object passed to
gtk_builder_connect_signals() in GTK3.
... and use it. This function looks up an object like
gtk_builder_get_object() but generates an error on failure.
Unlike the evil function _gtk_builder_lookup_object() which also
generates an error but hides it for later lookup.
Use this to avoid continuing applying properties when an error was
encountered.
- Propagate the error back to the parser, so we get a proper GError
instead of a g_warning().
- Connect closures by id, don't construct a name from the ids so that
glib can take it apart again.
gtk_builder_connect_signals() is no longer necessary, because all the
setup that made it necessary to have this extra step is now done
automatically via the closure functions.
This will be the future way to connect signals automatically (and be
used for other things, too).
For now, gtk_builder_connect_signals_default() is ported to use it.
This is pretty unused and gets in the way of the next steps.
A potential side effect is that for templates the widget was passed as
the user data argument. If that turns out to be important, we have to
special case that situation.
In addition to <property name="foo">bar</property> referring
to an object with ID bar, we now also parse
<property name="foo"><object>...
to specify a property 'inline'.
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.
In particular, allow specifying a filename for a GDK_TYPE_TEXTURE
property. This makes it easy to transition properties from Pixbuf type
to Texture type without having to touch resource files.
Instead of the deprecated g_object_newv().
This requires some internal surgery to create our own vector of names
and values, but it does not functionally change anything.
GLib has deprecated GParameter and g_object_newv(); until we switch to
the new g_object_new_with_properties() API, and bump GLib required
version, we should simply ignore the compiler warnings.
