These are too sensitive to rendering differences
between renderers to run reliably in ci, but we
still want to keep them around. In particular,
the big glyph tests are useful to exercise the
GL glyph cache.
The code previously forgot to include the left child of the model's
node. Which of course only happened if that child wasn't NULL, which is
a common case.
Found and test provided by Matthias Clasen.
Instead of playing games with mapping negative symbolic values to
positive ones, let's use the appropriate constants everywhere. This
allows us to use:
GTK_CONSTRAINT_STRENGTH_WEAK * 2
Or
GTK_CONSTRAINT_STRENGTH_STRONG + 1
In code using the public API.
We also store the strength values as integers, so we can compare them
properly, and only turn them into doubles when they are inserted into
the solver, just like every other variable.
Make the 'repeat edit' test make more than to
suggestions in a single edit phase. It turns out
that this does not work, whereas just doing
two in a row does.
GtkConstraintSolver is an implementation of the Cassowary constraint
solving algorithm:
http://constraints.cs.washington.edu/cassowary/
The Cassowary method allows to incrementally solve a tableau of linear
equations, in the form of:
x = y × coefficient + constant
with different weights, or strengths, applied to each one.
These equations can be used to describe constraints applied to a layout
of UI elements, which allows layout managers using the Cassowary method
to quickly, and efficiently, lay out widgets in complex relations
between themselves and their parent container.
Differentiate between wrapping around and
stopping at the end of the focus chain.
Update the existing tests, and add two
new ones where the difference matters.
Add a test that enumerates the focus chain by
emitting move-focus repeatedly, and compares
the result to expected output.
The test expects a ui file and a reference
file as input. The reference file can be created
using the --generate option.
If somebody does a transform like
scale(5) scale(10) translate(1,1) translate(5,0)
store it instead as
scale(50) translate(6,1)
This way, less memory is consumed and transforms are easier to read.
In particular, this simplifies the typical transforms we do in GTK,
which are just one translation after another.
We don't need to just look at the scale of the new modelview matrix, but
at the one we get when multiplying the new one with the current one.
Test case attached.
