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.
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.
The differenciation between a literal color value and an RGBA value
caused problems in various situations. Just treat the two the same but
don't allow access to the rgba value of a non-literal color value.
This gets rid of around 1.6k rgba values in the widget-factory.
Remove arguments from the constructor.
For actions, we now default to COPY, which is the most common one
that we should enable by default (MOVE requires handling deletion
on the the source side, and ASK only makes sense if we have
multiple actions).
For the content provider, we add a new ::prepare signal where
it should be provided just-in-time.
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.
We need to manually set up the css node,
since the treeview has children whose css
node is not a direct child of the treeview
css node (header buttons).
... 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.
The cairo pattern in use was simple enough, so just use a 2×1 or 1×2
texture to draw horizontal and vertical grid lines. This avoids a bunch
of cairo nodes (that can't be cached by the renderers).
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.
