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

Improve conflict resolution between hugging container with filling submorphs #1562

Open
linusha opened this issue Jun 4, 2024 · 0 comments

Comments

@linusha
Copy link
Contributor

linusha commented Jun 4, 2024

image

In the above image, the selected morph is the tall, red one in the back. As can be seen, its width mode is set to hug.
Inside of it, there are two morph, one for each row. The top one has fixed dimensions and is thus "safe", for the purposes of this ticket. The bottom has its extent set to fill.

My logic when building this was that I knew the top one was wider than the bottom one needed to be, so I wanted a quick way to let the bottom one "adapt" to the top one.

The result is however that the container shrinks and the fill of the bottom one is extremely small as well, as they both fight.

I see two problems with this:

  1. We should think about preventing really conflicting configurations via tooling, for example by just determining which option we override via convention. This is already coded, but the resolution mechanism is unsatisfying, see below
  2. I do not think that this configuration having this result is logical, as the resulting width of the container is smaller than the fixed top morph, which should have stopped the hugging from shrinking already.
@linusha linusha changed the title Tooling should prevent fighting cases of hug vs. fill Tooling should prevent fighting cases of "hug vs. fill" Jun 4, 2024
@linusha linusha changed the title Tooling should prevent fighting cases of "hug vs. fill" Improve conflict resolution between hugging container with filling submorphs Jun 4, 2024
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

1 participant