This is like G_DECLARE_FINAL_TYPE(), except it doesn't make the class
struct public, so internally all the subclassing in the world can
happen.
Some subtle differences:
- It marks the get_type() function as G_GNUC_CONST
- It doesn't require the parent type
- It uses G_DEFINE_AUTOPTR_CLEANUP_FUNC() instead of the private glib
chainup method.
Port a bunch of GDK and the whole event controller + gesture machinery
to provew that it works.
As a side effect, we gained a bunch of missing autocleanups.
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.
I have no idea where it should go really - maybe glib?
It certainly shouldn't require everybody including selectionmodel code
just to get at this value.
Otherwise the icon "jumps" to the cursor position with its top left when
the animation starts.
This is especially visible if the dragged item is big, like when dragging
mails in Thunderbird.
All the list model tests were leaking items,
because g_list_model_get_item is transfer full.
Fixing these unveils a crash in the treelistmodel
and maplistmodel tests.
We're a normal application, so we can use the normal way to hook up code
into builder files, which is using dlsym() for the function pointers.
There's no need to to extra work exporting static symbols.
