This is a scary idea where you #define a bunch of preprocessor values
and then #include "gdkarrayimpl.c" and end up with a dynamic array for
that data type.
See https://en.wikipedia.org/wiki/X_Macro for what's going on.
What are the advantages over using GArray or GPtrArray?
* It's typesafe
Because it works like C++ templates, we can use the actual type of
the object instead of having to use gpointer.
* It's one less indirection
instead of 2 indirections via self->array->data, this array is
embedded, so self->array is the actual data, and just one indirection
away. This is pretty irrelevant in general, but can be very noticable
in tight loops.
* It's all inline
Because the whole API is defined as static inline functions, the
compiler has full access to everything and can (and does) optimize
out unnecessary calls, thereby speeding up some operations quite
significantly, when full optimizations are enabled.
* It has more features
In particular preallocation allows for avoiding malloc() calls, which
can again speed up tight loops a lot.
But there's also splice(), which is very useful when used with
listmodels.
Instead of an array of arrays, let's use an array of dictionaries; it's
easier to add optional keys without requiring to remember where to put
empty arrays.
char ** arrays are null-terminated everywhere, so make sure they are in
splice(), too.
Also fix the argument to be a const char * const * like in the
constructor.
Simplify all view model APIs and always return G_TYPE_OBJECT as the
item-type for every model.
It turns out nobody uses item-type anyway.
So instead of adding lots of APIs, forcing people to think about it and
trying to figure out how to handle filter or map models that modify item
types, just having an easy life is a better approach.
All the models need to be able to deal with any type of object going
through anyway.
Verify that the selection filter changes mirror
the selection changes of the underlying model,
as expected. These tests verify the fixes in
the previous commit.
One of the widget-factory focus tests is flaky in ci,
perhaps due to font changes causing size computations
to go slightly differently.
Drop this for now.
Always keep the order:
- [value]
- [marks.top]
- [marks.bottom]
- trough
Which makes sense given the rendering order. Slider should be drawn
after the marks.
Makes it possible to simply remove the custom snapshot implementations
in scale and range. And Adwaita does not depend on the node order
anyway.
In particular, track which items remain in ::items-changed
signal emissions.
But the main use case is sorting, which causes items-changed(0, n, n)
to be emitted.
In 99.9% of all cases, these are just NULL, NULL.
So just do away with these arguments, people can
use the setters for the rare cases where they want
the scrolled window to use a different adjustment.
This is a list model holding strings, initialized
from a char **. String lists are buildable as well,
and that replaces the buildable support in GktDropDowns.
