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.
We don't expect out of tree implementations of GtkRoot, and having the
interface structure private to the GTK code allows us to add virtual
functions involving private types.
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.
