emeus
emeus copied to clipboard
Constraints' minimum sizes are not consistent
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.
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
- the parent's leading attribute is equal to the leading attribute of
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.
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.