Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ptomato opened this issue Dec 20, 2016 · 3 comments
Open

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

ptomato opened this issue Dec 20, 2016 · 3 comments

Comments

@ptomato
Copy link
Contributor

ptomato commented Dec 20, 2016

I've been experimenting with translating some examples from Apple's autolayout code to Emeus. Here is my translation of http://commandshift.co.uk/blog/2013/01/31/visual-format-language-for-autolayout/, as a gist: https://gist.github.com/ptomato/4f43834abc431705f515985fd8b53fcf

(To run it, download the two files from the gist, fetch the picture with wget -O kitten.jpg http://placekitten.com/150/150, and run gjs kitten.js.)

If you run the example with the short label string in headline, it looks perfect:
screenshot from 2016-12-20 15-46-21

However, if you comment out the short string and uncomment the long string, the constraint layout doesn't make room for the label's height:
screenshot from 2016-12-20 15-46-33

I suspect this is because the constraint layout is only taking the label's minimum height (the height that it would be if it had infinite width) into account and not its natural height.

@tchx84
Copy link
Contributor

tchx84 commented Dec 22, 2016

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
Copy link
Owner

ebassi commented Jan 3, 2017

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
Copy link
Contributor Author

ptomato commented Jan 3, 2017

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants