Aside from working on GSK, a long-running side project of mine is to write and add new layout policy that is based on constraints instead of fixed positioning and boxes-within-boxes; I've been meaning to add this to GTK+ since the time I wrote a naïve implementation inside Clutter, years ago, and now I got to do it properly for my work at Endless.
GUI toolkits have different ways to lay out the elements that compose an application’s UI. You can go from the fixed layout management — somewhat best represented by the old ‘90s Visual tools from Microsoft; to the “springs and struts” model employed by the Apple toolkits until recently; to the “boxes inside boxes inside boxes” model that GTK+ uses to this day. All of these layout policies have their own distinct pros and cons, and it’s not unreasonable to find that many toolkits provide support for more than one policy, in order to cater to more use cases.
For instance, while GTK+ user interfaces are mostly built using nested boxes to control margins, spacing, and alignment of widgets, there’s a sizeable portion of GTK+ developers that end up using GtkFixed or GtkLayout containers because they need fixed positioning of children widget — until they regret it, because now they have to handle things like reflowing, flipping contents in right-to-left locales, or font size changes.
Additionally, most UI designers do not tend to “think with boxes”, unless it’s for Web pages, and even in that case CSS affords a certain freedom that cannot be replicated in a GUI toolkit. This usually results in engineers translating a UI specification made of ties and relations between UI elements into something that can be expressed with a pile of grids, boxes, bins, and stacks — with all the back and forth, validation, and resources that the translation entails.
It would certainly be easier if we could express a GUI layout in the same set of relationships that can be traced on a piece of paper, a UI design tool, or a design document:
- this label is at 8px from the leading edge of the box
- this entry is on the same horizontal line as the label, its leading edge at 12px from the trailing edge of the label
- the entry has a minimum size of 250px, but can grow to fill the available space
- there’s a 90px button that sits between the trailing edge of the entry and the trailing edge of the box, with 8px between either edges and itself
Sure, all of these constraints can be replaced by a couple of boxes; some packing properties; margins; and minimum preferred sizes. If the design changes, though, like it often does, reconstructing the UI can become arbitrarily hard. This, in turn, leads to pushback to design changes from engineers — and the cost of iterating over a GUI is compounded by technical inertia.
For my daily work at Endless I’ve been interacting with our design team for a while, and trying to get from design specs to applications more quickly, and with less inertia. Having CSS available allowed designers to be more involved in the iterative development process, but the CSS subset that GTK+ implements is not allowed — for eminently good reasons — to change the UI layout. We could go “full Web”, but that comes with a very large set of drawbacks — performance on low end desktop devices, distribution, interaction with system services being just the most glaring ones. A native toolkit is still the preferred target for our platform, so I started looking at ways to improve the lives of UI designers with the tools at our disposal.
Expressing layout through easier to understand relationships between its parts is not a new problem, and as such it does not have new solutions; other platforms, like the Apple operating systems, or Google’s Android, have started to provide this kind of functionality — mostly available through their own IDE and UI building tools, but also available programmatically. It’s even available for platforms like the Web.
What many of these solutions seem to have in common is using more or less the same solving algorithm — Cassowary.
Cassowary is:
an incremental constraint solving toolkit that efficiently solves systems of linear equalities and inequalities. Constraints may be either requirements or preferences. Client code specifies the constraints to be maintained, and the solver updates the constrained variables to have values that satisfy the constraints.
This makes it particularly suited for user interfaces.
The original implementation of Cassowary was written in 1998, in Java, C++, and Smalltalk; since then, various other re-implementations surfaced: Python, JavaScript, Haskell, slightly-more-modern-C++, etc.
To that collection, I’ve now added my own — written in C/GObject — called Emeus, which provides a GTK+ container and layout manager that uses the Cassowary constraint solving algorithm to compute the allocation of each child.
In spirit, the implementation is pretty simple: you create a new
EmeusConstraintLayout widget instance, add a bunch of widgets to it, and
then use EmeusConstraint objects to determine the relations between
children of the layout:
let button1 = new Gtk.Button({ label: 'Child 1' });
this._layout.pack(button1, 'child1');
button1.show();
let button2 = new Gtk.Button({ label: 'Child 2' });
this._layout.pack(button2, 'child2');
button2.show();
let button3 = new Gtk.Button({ label: 'Child 3' });
this._layout.pack(button3, 'child3');
button3.show();
this._layout.add_constraints([
new Emeus.Constraint({ target_attribute: Emeus.ConstraintAttribute.START,
relation: Emeus.ConstraintRelation.EQ,
source_object: button1,
source_attribute: Emeus.ConstraintAttribute.START,
constant: -8.0 }),
new Emeus.Constraint({ target_object: button1,
target_attribute: Emeus.ConstraintAttribute.WIDTH,
relation: Emeus.ConstraintRelation.EQ,
source_object: button2,
source_attribute: Emeus.ConstraintAttribute.WIDTH }),
new Emeus.Constraint({ target_object: button1,
target_attribute: Emeus.ConstraintAttribute.END,
relation: Emeus.ConstraintRelation.EQ,
source_object: button2,
source_attribute: Emeus.ConstraintAttribute.START,
constant: -12.0 }),
new Emeus.Constraint({ target_object: button2,
target_attribute: Emeus.ConstraintAttribute.END,
relation: Emeus.ConstraintRelation.EQ,
source_attribute: Emeus.ConstraintAttribute.END,
constant: -8.0 }),
new Emeus.Constraint({ target_attribute: Emeus.ConstraintAttribute.START,
relation: Emeus.ConstraintRelation.EQ,
source_object: button3,
source_attribute: Emeus.ConstraintAttribute.START,
constant: -8.0 }),
new Emeus.Constraint({ target_object: button3,
target_attribute: Emeus.ConstraintAttribute.END,
relation: Emeus.ConstraintRelation.EQ,
source_attribute: Emeus.ConstraintAttribute.END,
constant: -8.0 }),
new Emeus.Constraint({ target_attribute: Emeus.ConstraintAttribute.TOP,
relation: Emeus.ConstraintRelation.EQ,
source_object: button1,
source_attribute: Emeus.ConstraintAttribute.TOP,
constant: -8.0 }),
new Emeus.Constraint({ target_attribute: Emeus.ConstraintAttribute.TOP,
relation: Emeus.ConstraintRelation.EQ,
source_object: button2,
source_attribute: Emeus.ConstraintAttribute.TOP,
constant: -8.0 }),
new Emeus.Constraint({ target_object: button1,
target_attribute: Emeus.ConstraintAttribute.BOTTOM,
relation: Emeus.ConstraintRelation.EQ,
source_object: button3,
source_attribute: Emeus.ConstraintAttribute.TOP,
constant: -12.0 }),
new Emeus.Constraint({ target_object: button2,
target_attribute: Emeus.ConstraintAttribute.BOTTOM,
relation: Emeus.ConstraintRelation.EQ,
source_object: button3,
source_attribute: Emeus.ConstraintAttribute.TOP,
constant: -12.0 }),
new Emeus.Constraint({ target_object: button3,
target_attribute: Emeus.ConstraintAttribute.HEIGHT,
relation: Emeus.ConstraintRelation.EQ,
source_object: button1,
source_attribute: Emeus.ConstraintAttribute.HEIGHT }),
new Emeus.Constraint({ target_object: button3,
target_attribute: Emeus.ConstraintAttribute.HEIGHT,
relation: Emeus.ConstraintRelation.EQ,
source_object: button2,
source_attribute: Emeus.ConstraintAttribute.HEIGHT }),
new Emeus.Constraint({ target_object: button3,
target_attribute: Emeus.ConstraintAttribute.BOTTOM,
relation: Emeus.ConstraintRelation.EQ,
source_attribute: Emeus.ConstraintAttribute.BOTTOM,
constant: -8.0 }),
]);
A simple grid
This obviously looks like a ton of code, which is why I added the ability to describe constraints inside GtkBuilder XML:
<constraints>
<constraint target-object="button_child"
target-attr="center-x"
relation="eq"
source-object="super"
source-attr="center-x"
strength="required"/>
<constraint target-object="button_child"
target-attr="EMEUS_CONSTRAINT_ATTRIBUTE_CENTER_Y"
relation="eq"
source-object="super"
source-attr="center-y"/>
<constraint target-object="button_child"
target-attr="width"
relation="ge"
constant="200"
strength="EMEUS_CONSTRAINT_STRENGTH_STRONG"/>
</constraints>
Additionally, I’m writing a small parser for the Visual Format Language used by Apple for their own auto layout implementation — even though it does look like ASCII art of Perl format strings, it’s easy to grasp.
The overall idea is to prototype UIs on top of this, and then take advantage of GTK+’s new development cycle to introduce something like this and see if we can get people to migrate from GtkFixed/GtkLayout.