Constraints should take height-for-width widget sizes into account

[ptomato]

Constraints should take height-for-width widget sizes into account

[tchx84]

I hit a similar problem while working on arrangements for eos-knowledge-lib, I sent a PR to fix it #20 (or part of the problem at least).

Without my patch the issue happens 100% of the times, but even with my patch it can still happen (but rarely).

So, after some tests, I noticed that removing the (>=0) predicate from this constraint definition completely "solves" the issue (as I can't reproduce at all).

So it seems that my patch fixes one part of this issue, but there is still something happening with the (>=0) predicate that causes that behavior.

[ebassi]

To be fair, this obsession with (>=0) is somewhat suspicious to begin with. ;-)

Additionally, it's important to note that, absent a @ annotation, all constraints expressed in VFL are required by default when solving the layout. If there are ambiguities or conflicts in the solver, you're going to get unstable layouts.

I merged PR #20, and I think the example is just pointing to an unstable layout that wasn't thoroughly tested.

Apple spent a lot of time explaining to developers that autolayout can be unstable or ambiguous, so I don't think taking examples from a random blog post from 2013 as a reliable source is a good idea. Unless, of course, you can take those examples and run them on macOS, and get stable results; in which case, it's definitely a bug in Emeus.

[ptomato]

taking examples from a random blog post from 2013 as a reliable source

Guilty :-) I pretty much googled "autolayout example" and tried to implement a likely-looking one in Emeus. It would be nice to have more exciting examples in Emeus though; do you have any suggestions on how to tell the good from the bad?

(>=0) seemed to me a way to build a variable spacing into the constraint system, but from #19 I understand that maybe I should be using lower priorities instead?