using a constant in equalTo() and adding an offset doesn't work about masonry HOT 14 CLOSED

Sorry for the very delayed response, have been away on holiday.
Any changes to the constraint constant are not additive. So last method call to change the constraint constant wins. Since .offset() and other methods that modify the constraint constant can be called outside of makeConstraints block for animation etc

from masonry.

Let me know if you have any suggestions/solutions otherwise closing for now. thanks

from masonry.

@cloudkite I believe this is worth implementing, what do you think? It makes a lot of sense and should be pretty easy to do. I wanna try it :)

from masonry.

I think it should work like this:

MASConstraint *constraint = make.width.equalTo(200).with.offset(-40); // result = 160
...
constraint.offset = 100; // result = 300

On a side note, are we really supposed to be using methods like .offset() outside of a constraint maker block?

from masonry.

@nickynick offset, insets, sizeOffset etc need to be called outside of a constraint maker block inorder to update constraints for animation etc.

I think having offset being additive would be very confusing, the developer would need to make sure they remember they have previously set an offset

Having a cumulative offset seems to me like it would cause alot of confusion

constraint.offset = 100; // result = 300

from masonry.

@cloudkite

offset, insets, sizeOffset etc need to be called outside of a constraint maker block inorder to update constraints for animation etc.

That's right, what I wanted to say was that it feels much more intuitive to write constraint.offset = 100; rather than constraint.offset(100);. Anyway, having both of these available publicly is a bit confusing.

I think having offset being additive would be very confusing, the developer would need to make sure they remember they have previously set an offset

Why? You are thinking of offset as if it was an alias for "layout constant", but that's not really the case, IMO. A big cool thing about Masonry is that it allows you to write constraint code as sentences. So, to create a constraint, first you make it equal to something, and then you can specify an offset from that thing. It is absolutely expected when you relate to views and view attributes, and, to me, it's quite the same when you relate to values. First you specify a value, and then you can tweak it a bit by adding an offset.

from masonry.

And also, having to remember that you previously set an offset is not a problem, I think it should be like this:

MASConstraint *constraint = make.width.equalTo(200).with.offset(50); // width = 250
...
constraint.offset = -50; // width = 150
constraint.equalTo(300); // offset is reset, width = 300
constraint.offset = 100; // width = 400

from masonry.

However if you are relating the constraint to a view such
make.left.equalTo(otherView);

In this case you have no means of reseting the offset. As equalTo(200) can only be used if you are specifying constraints relative to the superview

from masonry.

Well, actually, I would expect that an equalTo() called on existing constraint will always give me a fresh relation, overriding previous offsets. In this example, why would you want to preserve an offset of 30?

constraint = make.left.equalTo(otherView).with.offset(30);
// or constraint = make.left.equalTo(0).with.offset(30);
...
constraint.equalTo(100);

Perhaps I didn't quite understand your point, could you elaborate please?

from masonry.

Yeah you are right :) thought there were special assertions on equalTo as number but that's just on install time and doesn't apply outside of a maker block. What you are proposing makes sense, I'm just not entirely convinced there is enough benefit gained in changing offset to be cumulative to justify breaking existing projects?

from masonry.

I'm not sure either, to be honest :)
On one side, the current behaviour of example described by @ahti is pretty confusing. However, if we change it, I can see how this could be confusing as well:

constraint = make.left.equalTo(50);
constraint.offset = 100; // 50 + 100 :P

Maybe it makes sense to establish that using numbers for edge & position relations (make.left.equalTo(50)) is essentially just a shorthand for superview relation + offset (make.left.equalTo(superview).with.offset(50))? This doesn't look confusing to me:

constraint = make.left.equalTo(100).with.offset(200); // you just get 200 here
constraint.offset = 300; // 300

from masonry.

In other words, this offset thing would only be cumulative for size constraints :)

from masonry.

Well, after all, perhaps it doesn't matter that much to introduce additional complex logic and potentially break someone's code for sake of implementing it :)

from masonry.

Maybe it's just worth to spawn a log message when overwriting a layout constant on a constraint which has not yet been installed? Like, "hey buddy, you might not get what you expect".

from masonry.