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.
Replace uses of gtk_css_style_get_value with direct access,
throughout the tree. We don't replace all uses, just those
where we are dealing with a fixed property. Be careful to
handle the currentColor special case for color properties.
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.
The reason for this is simply that I want to get hash functions that
have their values close together, so they can fit in a smaller range
(the goal here is 12 bits). By using GQuark, we get consecutive numbers
starting with 1 (and applications have <1000 quarks usually), whereas
interned strings can be all over the place.
As a side effect we also save 64 bytes per declaration.
Previously, we wrapped all GtkCssShadowValues in a GtkCssShadowsValue,
even if it was just one shadow. This causes an unnecessary bloat in
css values.
Make each GtkCssShadowValue able to handle multiple shadows instead, and
use gtk_css_shadow_value* API everywhere.
I was seeing crashes in gtk_widget_run_controllers.
We were accessing the controller after calling out
to application code that might remove it. Better
be safe and do the access before.
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 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.
... inside the default vfunc.
Instead, walk the children until we find the first widget that can be
focused. If no child can be focused, return FALSE from grab_focus.
The value returned by gtk_widget_get_settings() depends on the widget's
display, so watch for notify::display instead of using (un)root for
this.
Fixes the warnings seen when show a file chooser from the inspector.
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.
We need to create a muxer eagerly for every
widget that has class actions, since those
are otherwise missed in the action lookup
on the muxer side. But otherwise, there is
no reason to create parent muxers aggressively,
as long as we update the parent muxers on
root/unroot.
This reduces the number of muxers we create
in widget-factory from 210 to around 50.
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.
Make gtk_widget_real_focus do the right
thing for focusable widgets with children.
A case where this is (now) relevant is
an entry with a context popover.
We don't need to cover every case with a va_marshaller, but there are a
number of them that are useful because they will often only be connected
to by a single signal handler.
Generally speaking, if I opened into a file to add a va_marshaller, I just
set all of them.
Similar to previous removals of g_cclosure_marshal_VOID__VOID we can remove
other marshallers for which are a simple G_TYPE_NONE with single parameter.
In those cases, GLib will setup both a c_marshaller and va_marshaller for
us. Before this commit, we would not get a va_marshaller because the
c_marshaller is set.
Related to GNOME/Initiatives#10
The CSS transform should operate on the border-box, not the margin box.
So we need to shrink the bounds by the margin before we apply the CSS
transform.
Make the transform (transfer full).
1. This makes sure we actually reference the transform. Previously we
did not.
2. Most callers create a new transform to pass to us. Now they don't
have to uref it anymore.
When a GtkNative widget is marked as resize_needed,
we need a current position for its parent and we need
the parent to be allocated (so we can position our
surface), but we don't need the parent to be marked
as resize_needed, since the parent size is entirely
independent of the popup size.
When we print warnings about a widget, using
gtk_widget_get_name() is slightly better than
G_OBJECT_TYPE_NAME(), since it will give us
the widgets unique name when available.
Now that roots can have parent widgets, we need to
carefully examine all calls of gtk_widget_get_toplevel,
and replace them with gtk_widget_get_root if we want
the nearest root, and not the ultimate end of the parent
chain.
The GTK_DISPLAY_DEBUG_CHECK macro will cleverly only call the function
if any of the display debug flags are set, so in the common case it
won't even be executed.
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.
Export gtk_widget_root/unroot privately,
make them work on roots, and use them in
gtk_window_set_display. This gets us to a
single way to listen for display changes,
the root property.
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.
We used to handle has-default specially in ui
files. It was awkward, so stop doing that. If you
need to influence the default widget in a window,
you can just set the default-widget property.
We used to handle has-focus in ui files specially.
It was awkward, so stop doing that. If you need
to influence the initial focus of a window, you
can just set the focus-widget property.
