This is implemented as a auxiliary object that
generates a bunch of constraints (and variables)
when added to a constraint layout.
Maybe this could be generalized to a 'constraint
set' concept, if we come up with other layouts
that we want to reimplement in this way.
Only constraint the opposite direction if we
actually have a for_size, and measure natural
size after removing the edit constraints. With
these changes, the test that compares constraint
layout to grid layout passes.
It makes more sense to treat the natural size
of both children and guides as stays, since
we want to meet these values as closely as we
can, under the circumstances.
Set up all constraints for minimum + natural
width + height when measuring, regardless
of the orientation we're measuring. Anything
else will lead to incorrect answers when
there are constraints that cut across
dimensions.
This test produces a very simple layout and
checks that it produces the same numbers as
an equivalent grid layout. Currently, it fails,
since the constraint layout can't produce
minimum sizes that are different from natural
sizes.
We don't want the edit constraints to be required,
since we want to violate them when the pointer moves
off the edge. Make them strong instead, and now
everything just works.
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.
The marker variables table does not acquire a reference on the
constraint variables it contains, as they are part of the constraint
used as the key, and will be released when the constraint is removed.
Make it possible to build tests which use
GtkConstraintSolver from inside and outside libgtk.
See the test added in the following commit for
how this is used.
This commit moves GtkConstraintGuide into its own
source files to avoid gtkconstraintlayout.c turning
too messy, adds max size properties and implements
getters and setters.
We cannot use the given "for size" when querying our children, because
the constraint layout has no idea about the opposite size of its
children until the layout is complete.
Additionally, we should only suggest an opposite size for the layout if
we have one, instead of suggesting a weak zero size.
The size constraints are transient to measurement and allocation, so
they don't really need to be stored inside the GtkLayoutChild subclass
created by a GtkConstraintLayout.
The relations between left, right, width
and top, bottom, height are required for
internal consistency. It doesn't make sense
to ever drop these.
Changing the strength of these relations makes
my systems behave much more stable.
When the solver is finalized with existing
constraints, we end up with criticals when
the constraints ref finalize code calls
back into the hash table. Avoid that by
emptying the hash table beforehand.
