What would active resizing constraints look like?

[SaadArdati]

Hello, I've been exploring the library and it's been great, however I was wondering if I could get help building constraints for a specific case.

Imagine I make a box. It's easy to add constraints for a normal box, it would just look something like

[
        pos.top >= cm(0),
        pos.left >= cm(0),
        pos.right >= cm(0),
        pos.bottom >= cm(0),
        (pos.right).equals(pos.left + pos.w) | Priority.strong,
        (pos.bottom).equals(pos.top + pos.h) | Priority.strong,
        (pos.centerX).equals((pos.left + pos.right) / cm(2.0)) |
            Priority.strong,
        (pos.centerY).equals((pos.top + pos.bottom) / cm(2.0)) |
            Priority.strong,
      ];

This is just describing a solid box. I set the right/bottom/centerX/centerY to strong because other constraints may want to modify the size later on.

For translating the top and left position, we just do

[
      (pos.left).equals(bounds.left + cm(offset.dx)) | Priority.strong,
      (pos.top).equals(bounds.top + cm(offset.dy)) | Priority.strong,
]

This is making so if the offset x/y change, the left and top must change (theoretically)

Changing the width and height works well too, the right and bottom edges resize as needed and the top and left edges remain in place. This is because the constraints are satisfied well.

To get width/height to work, we add the following constraints:

[
    (pos.right).equals(pos.left + cm(width)) | Priority.required,
    (pos.bottom).equals(pos.top + cm(height)) | Priority.required,
]

This is making so if the width or height change, the right and bottom edges must change (theoretically).

The offset, width and height may change, when they do, the solver rebuilds the constraints with the updated values.

However, if you resize from the top left corner, or the top corner, or the left corner, you will translate the box instead of resize + change top/left. I expected the translation constraints to run, finish, then the sizing constraints to run, then finish, but clearly that's not what's happening. So I was wondering what flaw exists in my logic when thinking about this.

I wanted to translate, and then resize, not simutaeniously. Should I flush translation first then flush resize second to enforce an order?
My best guess is that Stays have not been implemented here and the solver is forcing the equation by changing the width and height variables, which are unused. Like if Stays existed, I would've set width/height to stayed values so they don't change.

[domesticmouse]

I don't fully understand the algorithm, I was merely resurrecting it from Flutter's Git history.

To fully understand the algorithm's actions in your use case I'd suggest writing lots of test cases and seeing how it performs. The scientific discovery approach, if you will.

[SaadArdati]

Okay thank you