1. Rename the thing
2. Turn it from a signal to a vfunc
3. Pass the GtkCssStyleChange to it
We don't export any public API about the GtkCssStyleChange yet, it's
just a boring opaque struct.
Add GtkWidget API for adding and removing style classes, as well as
checking whether a widget has a style class applied.
Everyone has to go through GtkStyleContext for this these days but with
GtkStyleContext eventually going away, it makse sense for GtkWidget to
have API for this.
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.
I recently turned gtk_widget_activate_action()
into a varargs function. That is more convenient
from C, but we need a non-varargs variant for
bindings. So add the old API back, under the
name gtk_widget_activate_action_variant(),
with a rename-to annotation.
The only cases of stateful actions we've seen
so far have been boolean properties, and we
don't really want to add much state handling
API, so lets just go with property actions
for now.
Adapt the only user in GtkText.
Add a facility to register and install actions
at class init time. The intended use for these
actions is for
a) context and other model-based menus
b) key bindings
Most of these actions are going to be stateless,
so add separate apis for the simple and stateful
cases.
We avoid creating an action group for these by
teaching the action muxer about these actions.
The action muxer also maintains the enabled
state for these actions.
Add a convenience api to skip children
that should not be included in the layout,
and call gtk_native_check_resize on all
native children outside of the vfunc.
Ensure that the class structs of all subclassable
types have sufficient padding (standardizing on 8
slots, here).
GtkApplication
GtkWidget
GtkContainer
GtkWindow
GtkDialog
GtkApplicationWindow
GtkToolItem
GtkBin
The inspector, and other tools introspecting the widget structure like
gtk-builder-tool and Glade, may very well want to access the default
layout manager used by a class, especially if there are layout
properties involved, without having a whitelist of widget/layout manager
associations.
Some widgets have a well-defined layout manager created alongside their
own instance; if they do, we can handle the layout manager creation at
the GtkWidget instantiation.
Display changes now happen exclusively through
the ::root and ::unroot vfuncs. Third parties
can observe display changes by listening
for notify::root.
The default widget is mostly a dialog concept,
and does not really need this generic api.
If you need to mark a widget as default,
use gtk_window_set_default() directly.
This will be used to let the inspector and other users
pick insensitive widgets again. For now, update all
callers to pass no flags, preserving the current
behavior.
