Is there any difference between these two Constraints settings?

[mikeswarts]

Are these constraints identical or is there a subtle difference of some kind?

[v_kyr]

Quote

XCode -> Interface Builder ->  Viewing Constraints in the Canvas

The editor displays all the constraints affecting the currently selected view as colored lines on the canvas. The shape, stroke type, and line color can tell you a lot about the current state of the constraint.

• I-bars (lines with T-shaped end-caps). I-bars show the size of a space. This space can be either the distance between two items, or the height or width of an item.

• Plain lines (straight lines with no end-caps). Plain lines show where edges align. For example, Interface Builder uses simple lines when aligning the leading edge of two or more views. These lines can also be used to connect items that have a 0-point space between them.

• Solid Lines. Solid lines represent required constraints (priority = 1000).

• Dashed Lines. Dashed lines represent optional constraints (priority < 1000).

• Red Lines. One of the items affected by this constraint has an error. Either the item has an ambiguous layout, or its layout is not satisfiable. For more information, see the issues navigator or the disclosure arrow in Interface Builder’s outline view.

• Orange Lines. Orange lines indicate that the frame of one of the items affected by this constraint is not in the correct position based on the current set of constraints. Interface Builder also shows the calculated position for the frame as a dashed outline. You can move the item to its calculated position using the Resolve Auto Layout Issues tool > Update Frames command.

• Blue Lines. The items affected by the constraint have a nonambiguous, satisfiable layout, and the item’s frame is in the correct position as calculated by the Auto Layout engine.

• Equal Badges. Interface Builder shows constraints that give two items an equal width or an equal height as a separate bar for each item. Both bars are tagged with a blue badge containing an equal (=) sign inside.

• Greater-than-or-equal and less-than-or-equal badges. Interface Builder marks all constraints representing greater-than-or-equal-to and less-than-or-equal-to relationships with a small blue badge with a >= or <= symbol inside.

• Working with constrains in Interface Builder
• Understanding Auto Layout
• What means dotted constraint in Xcode 7?
• ... etc.

[R C-R]

@v_kyr, I think the OP is asking about the options in the AD Constraints panel. Unfortunately, that is something I know very little about.

[v_kyr]

17 minutes ago, R C-R said:

@v_kyr, I think the OP is asking about the options in the AD Constraints panel. Unfortunately, that is something I know very little about.

Ah Ok thought somehow Xcode is probably meant here, the OP should better always mention the app he is asking about! - However, things should be similar here then ...

• Constraints panel (... from @R C-R link shows that there are differences for solid and dashed lines too).
• Constraints

• Quote

  To anchor a child object to its parent's boundaries:

  1. Select a child object.
  2. On the Constraints panel, click a grayed-out dashed line between the inner and outer square to anchor the object to its parent in that direction (top, bottom, left, or right). A solid line means anchoring is being applied.

 

And just for fun the Android way here.

[R C-R]

FWIW, AD's help topics about constraints do not seem to mention anything about how "Lock Children" affects this, & there is no current official video tutorial about it. However, I remembered there was an older one (I think for v1.5) viewable at https://player.vimeo.com/video/182383578 on Vimeo which may make it clearer how this works.

[walt.farrell]

21 minutes ago, v_kyr said:

thought somehow Xcode is probably meant here, the OP should better always mention the app he is asking about!

But we should assume that questions here are about Affinity applications if they make sense in the Affinity context

[walt.farrell]

From the Constraints Help topic mentioned already,

Quote

On the Constraints panel, click the horizontal or vertical solid double arrow (or both) in the panel's inner square. A grayed-out dashed arrow means that scaling won't occur when its parent object is resized.

and

Quote

On the Constraints panel, click a grayed-out dashed line between the inner and outer square to anchor the object to its parent in that direction (top, bottom, left, or right). A solid line means anchoring is being applied.

 

[R C-R]

All the above aside, what is the answer to the OP's question? Is there any difference in their effect on the child objects & if so, what?

It might help if someone who understands how the constraints options work better than I do could post an example file showing the differences in behavior, assuming there are any.

I tried it a few times but could not come up with anything definitive....

Edited May 30, 2022 by R C-R

[v_kyr]

7 minutes ago, walt.farrell said:

But we should assume that questions here are about Affinity applications if they make sense in the Affinity context

Probably, though since in another thread the Op wrote "I'm working on an app interface for iOS ...", my daily developer oriented mind went then immediately to Xcode! 😉

[v_kyr]

37 minutes ago, R C-R said:

All the above aside, what is the answer to the OP's question? Is there any difference in their effect on the child objects & if so, what?

The video you referenced shows the differences! - When you disable (make them dashed) the inner straight horiz/vert lines for certain objects on an artboard, they don't scale/stretch anymore together with the artboard. That way you can force them (objects on the artboard) to keep their initial size, so they don't rescale. Though then in order to keep their position relative to their top view (artboard resizings) you have to setup the needed outer constraints to the artboard (otherwise they can disappear, be covered by other objects, when shrinking/resizing an artboard).

The whole controls & influences for objects their orientation, sizing and stretching behavior, relative to the superview they are placed on/in (an artboard for example). - The best is to play around with what the video shows, in order to better understand the constraits handling.

[R C-R]

7 minutes ago, v_kyr said:

The video you referenced shows the differences!

Where in that video do you see an example of how the two specific settings shown in the OP have a different effect?

[v_kyr]

1 hour ago, R C-R said:

Where in that video do you see an example of how the two specific settings shown in the OP have a different effect?

Didn't you looked it? - See from 02:25 on for the header etc. in the video you referenced!

Here's a short tryout take ...

 

 

[R C-R]

1 hour ago, v_kyr said:

Didn't you looked it? - See from 02:25 on for the header etc. in the video you referenced!

Yes, of course I looked at it. But where in that video or yours do you see the constraints set exactly the same as in the OP's two examples?

[thomaso]

7 hours ago, mikeswarts said:

Are these constraints identical or is there a subtle difference of some kind?

To finally come to your question: I say No. I can't experience a difference.

Appears logical. If both outer constraints in one direction (v/h) are activated, it forces scaling for this object, and thus an initially dimmed (gray) inner constraint is automatically displayed undimmed (white). The dashes seem to indicate that I have not set the inner constraint myself, but that it is influenced by my settings of the outer constraints (automatic).

Also, different than possibly expected, the constraint setting of a parent object is neither inherited by nor influencing a nested child object, instead each object has its own settings. Additionally I can set constraints for the entire Constraints Group layer but without any affect to its nested layout objects – unless this Constraints Group layer is nested inside a parent Constraint Group layer. Then constraints settings of the nested group do affect its contents and entirely override (knock-out) individual constraint settings of its child layers. To me, the Constraints Panel can be a useful, powerful tool but is also one more indicator for different developing minds having been involved in Affinity UI/UX design without the goal to avoid irritation / achieve fully intuition.

Special: if no constraints are activated (= all dimmed / dashed) in a group then still some constraint does happen. The objects don't get scaled + don't stick to their positions but move relative to the scaling of the Constraints Group. This can be a workaround for the missing feature to distribute objects unevenly / arrange them with flexible spaces without scaling them.

[v_kyr]

10 hours ago, R C-R said:

But where in that video or yours do you see the constraints set exactly the same as in the OP's two examples?

I didn't set them up exactly the OP's way in my screencast, since just changing the inner rects contraints from enabled/disabled won't change anything here in terms for the scaling of a child object. - Meaning, the more important part with scaling or not here for an child object are the outer rect line parts and as far as these remain the same (... are unchanged as shown initially by the OP) the child object behavior will be the same in either case.

[R C-R]

4 hours ago, v_kyr said:

I didn't set them up exactly the OP's way in my screencast, since just changing the inner rects contraints from enabled/disabled won't change anything here in terms for the scaling of a child object.

So then do you agree with @thomaso that there is no difference in the effect of the two settings the OP showed in the first post?

[mikeswarts]

Until a counter-example is demonstrated, I agree with @thomaso. I believe that when anchoring is enabled on both sides of an axis, the state of the corresponding double arrow (solid or dashed) has no effect. Thanks for everyone's responses.

[v_kyr]

2 hours ago, mikeswarts said:

I believe that when anchoring is enabled on both sides of an axis, the state of the corresponding double arrow (solid or dashed) has no effect.

That looks so far to be right! - I've also tried it with many deeper nested child objects on parent containers (...with Lock Children enabled and disabled for the parent container views) etc. and so far couldn't see any visual difference in behavior between both of your initially shown constraints settings.