Constraints' minimum sizes are not consistent

[ptomato]

Here's a GJS script that illustrates the bug:

const Emeus = imports.gi.Emeus;
const Gtk = imports.gi.Gtk;
Gtk.init(null);

let view = new Emeus.ConstraintLayout();
let widgets = {
    w1: new Gtk.Button({ label: "Hello" }),
    w2: new Gtk.Button({ label: "world" }),
};
view.add(widgets.w1);
view.add(widgets.w2);

let constraints = Emeus.create_constraints_from_description([
    "|-[w1(200)]-(>=0)-|",
    "|-[w2(300)]-(>=0)-|",
    "V:|-[w1]-(>=100)-[w2]",
], 15, 15, widgets, {});
constraints.forEach(view.add_constraint, view);

let win = new Gtk.Window();
win.add(view);
win.connect('destroy', Gtk.main_quit);
win.show_all();
Gtk.main();

When you run this, the initial size of the window (215x200) is big enough to take the vertical size of the layout and the horizontal size of w1 into account, but not the horizontal size of w2, which is cut off.

If you drag the window's lower right resize grip around in circles, you can get into one of two states: either (1) the window will not size smaller vertically than 200 pixels but will size horizontally down to 1 pixel wide, or (2) the window will not size smaller than 215x200 pixels. It's unclear to me how to reproducibly get into each state, but each time you restart the program and drag the resize grip around, you will get into one of the two. (Very rarely, you can even change by just frenetically dragging the resize grip without restarting the program.)

It seems to me that the minimum size should be more like 315x200 (to take w2 into account) and should be consistent no matter how many times you resize the window.

[ebassi]

If resizing changes the layout it's because the layout as defined by the constraints is not stable; this is usually caused by too few, or contradictory constraints.

Let's break down the VFL:

• |-[w1(200)]-(>=0)-| expands to:
  • the parent's leading attribute is equal to the leading attribute of w1, minus a constant default spacing
  • the width attribute of w1 is set to be a constant value of 200
  • the trailing attribute of the parent is equal to, or greater than the trailing attribute of w1, plus a constant spacing of 0

All these constraints are set to be required to solve the layout.

This is similar to the line below of |-[w2(300)]-(>=0)-| but the width is now different. The solver will try to size the parent into something that can contain both w1 and w2, but since there's no way to get a stable layout with all these required constraints, you're going to get into an unstable layout.

You can set a priority; for instance, you may want to lower the priority of the spacing between the trailing attribute of w1 and the parent's own trailing attribute; this would give precedence to the constraint between w2 and the parent.

You can also remove the constraint between the trailing attribute of w1 and the trailing attribute of the parent; after all, if you hardcode the width of w1 and you expect w2 to be bigger, then you don't need to attach the trailing edges together.

[ptomato]

I don't understand though why the >= operators don't make the layout stable. You can satisfy all the required constraints with a width of (300 + default spacing). Or am I misunderstanding how the greater-or-equal operator works? It sounds like instead of (>=0) I should be adding a (==0) constraint with a low priority.