We rely on a specific minimum version of gtk-doc to be able to build the
GTK API reference for the new API. In order to be able to use gtk-doc as
a subproject, though, we need to use a recent version of Meson.
This is a more modern way of doing things, and avoids a window
of type GTK_WINDOW_POPUP. With a popover, it doesn't make sense
to have a positioning function, so remove that api.
Do away with the proxy menu items, and instead
just have toolitems provide a label for overflow
items. We create the overflow widgets ourselves
already, as model buttons.
Also replace the toggle button used for overflow
with a menubutton, simplifying things further.
- Move into its own section
- Split GtkTreeListRow into its own document
Trees are weird with listmodels and they deserve their own treatment,
they shouldn't be mushed up with the rest of the list machinery.
... and use them.
Also, rename them from is/contains-pointer-focus to is/contains-pointer,
that's clear enough and not too long.
Finally, adapt the semantics of contains-pointer to mirror
GtkEventControllerKey::contains-focus. If is-pointer is set, so is
contains-pointer, they are not exclusive.
Which is what all users of this property wanted, too.
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.
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.
