Stay Variables

[Cacaodev cacaodev]

Hello,

What is the expected behavior for stay variables ?

Do they try to stay 1) with the same value as their initial value, or 2) as their current value which may have been modified directly (as an editVar) or indirectly after a break ?

From my tests it seems that in practice the answer is 1) but I would like a confirmation. In some occasions, it also seems to me that the behavior 2) is needed.

Thanks.

Martin.

[Greg Badros]

You shouldn't have both stay and edit contraints on the same variable.  All variables not being edited should stay at the same value between resolves unless a stronger constraint means their value needs to change. Once the value is changed by a resolve or a solve call, then there's a new stay constraint at that newly-set value, if any.

Hope that helps.

Greg

--
You received this message because you are subscribed to the Google Groups "overconstrained" group.
To unsubscribe from this group and stop receiving emails from it, send an email to overconstrain...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Russell]

Should we have the solver warn if you try to add both stay and edit constraints on the same variable?

[Greg Badros]

I think the current expected behaviour is for you to add stays on all variables, so it may just be better to automatically add stay constraints (it almost never makes sense to have a loose variable without a stay).  And I think if there's an edit constraint added, those are just done at a higher strength so they supersede the stay constraint.  I retract my remark the "shouldn't have both stay and edit constraints on the same variable" -- it's fine to do so, and the constraint hierarchy will do the right thing.  

Greg

[Cacaodev cacaodev]

Thank you for your answer.

I just would like a clarification because i am getting unexpected results when logging a modified StayConstraint. Maybe i am not using correctly the API or there is another problem.

Here is what i do:

- Create a stay variable, create a stay constraint.

- Add the stay constraint to the solver.

- Suggest a different value for the stay variable.

- log the stay constraint.

In the constraint description the stay variables acquires correctly its new value but the constant in the stay constraint is not updated.

At first, i though that maybe the constraint may have been changed internally and refers to nothing inside the solver. But if I try to remove it with removeConstraint(), nobody complains and getInternalInfo()  indicates that the number of constraints goes from 1 to 0, so i believe the constraint was in fact in the solver.

Here is a JSfiddle showing the steps : http://jsfiddle.net/cacaodev/Rv8bb/ (tested in Safari/Webkit)

Something is wrong either in the solver, the constraint description, or the way i am using it and i would like to understand what it is ...

[Ken Ferry]

On Sun, Apr 13, 2014 at 8:20 PM, Greg Badros <bad...@gmail.com> wrote:

I think the current expected behaviour is for you to add stays on all variables, so it may just be better to automatically add stay constraints (it almost never makes sense to have a loose variable without a stay).

FWIW, we went the opposite direction with Cocoa's system, and there is no "stay" concept. 

It seemed useful for predictability and debugging for layout to be a strict function of the user's constraints, not other state. Stays are sorta "path dependent" - you cannot tell what's going to happen just from the constraints created, you also have to know where things were a minute ago. If the layout is going wrong and needs to be debugged, that's a complicating factor.

The user can implement the equivalent of a stay themselves, if needed. Cocoa does for the size of a window on the Mac, for example.

[Håvard Fossli]

Ken, I'm trying to grasp what you are saying. Can you elaborate a little bit more? Or point me to somewhere I can read about this? 

Thanks

[kenf...@gmail.com]

On Wednesday, Sep 24, 2014 at 2:48 AM, Håvard Fossli <hfo...@agens.no>, wrote:

Ken, I'm trying to grasp what you are saying. Can you elaborate a little bit more?

I'm not sure what to elaborate on. :-) If you have a specific question, I can try to help. 

[Håvard Fossli]

LOL :D Sorry for being vague. I had a lot of questions at that point.

I gave what you have said about stay variables in the cocoa environment some extra thought. It seems very reasonable to omit it.

It would be awesome if you could explain in a few lines how the user can implement the equivalent of a stay themselves within auto layout. Knowledge is king :-)

[kenf...@gmail.com]

On Wednesday, Oct 8, 2014 at 5:19 AM, Håvard Fossli <hfo...@agens.no>, wrote:

LOL :D Sorry for being vague. I had a lot of questions at that point.

I gave what you have said about stay variables in the cocoa environment some extra thought. It seems very reasonable to omit it.

It would be awesome if you could explain in a few lines how the user can implement the equivalent of a stay themselves within auto layout. Knowledge is king :-)

Well, to go back to the same example, the size of a window behaves like it has a stay constraint.

What actually happens is that there are constraints window.width == <some number> and window.height == <some number> at a particular strength, and every time the window's frame gets set (due to a computation from the layout system), the constants in the constraints are updated to be the current actual window frame.

That's what stay constraints do internally anyway, this is just doing it from outside the solver.

-ken

[Håvard Fossli]

That makes sense. 

In case anyone wonders Ken is talking about the `constant` property on `NSLayoutConstraint`.