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 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.
I've seen a crash when the action muxer gets
disposed during widget destroy, and tries to
disconnect from widget signals too late.
There is no real need to disconnect, since the
only time an action muxer is going away is when
its widget is destroyed, so just don't do it.
I recently turned gtk_widget_activate_action()
into a varargs function. That is more convenient
from C, but we need a non-varargs variant for
bindings. So add the old API back, under the
name gtk_widget_activate_action_variant(),
with a rename-to annotation.
We need to create a muxer eagerly for every
widget that has class actions, since those
are otherwise missed in the action lookup
on the muxer side. But otherwise, there is
no reason to create parent muxers aggressively,
as long as we update the parent muxers on
root/unroot.
This reduces the number of muxers we create
in widget-factory from 210 to around 50.
