Solving anchored + animated widgets

[BeShifty]

After running into another case where I need anchored and animated widgets, I've come to the conclusion that NGUI needs to address this fairly common requirement and how it can be reconciled with the current anchoring system. The main issue arises due to the fact that it is no longer possible to match a widget's dimensions without also taking its position. The legacy components UIAnchor and UIStretch provided that ability. Here's an example that illustrates the problem:

Widget A (anchored to fill the left 1/4 of the screen)
- Various UI elements (anchored to Widget A in order to have correct dimensions/relative spacing)

Now what can I do to slide these elements on-screen from the left?
- I can't apply a TweenPosition to Widget A because its anchoring will override the tween.
- I can't apply TweenPositions to the sub-elements, because they still need to accept the dimensions from Widget A

My proposed solution is to add a control to UIRect that allows the user to toggle position and/or dimension matching. This new enum (or checkboxes) has three possible states: Position, Dimensions, or PositionAndDimensions. The only change in behaviour is that right before overwriting localPosition or mWidth/mHeight in UIWidget.OnAnchor:1231/1238, we check that we have an acceptable AnchorMode.

I believe this change to be low-risk, backward-compatible (default to PositionAndDimensions), and easy to communicate. Please let me know what you think.

[markofevil3]

I'm still using UIAnchor and UIStretch in some cases due to this limit. Hope they will have an update for this.

[ArenMook]

If you want to match dimensions of something, use EnvelopContent. That's exactly what the script was meant for. It can even resize one widget to envelop an arbitrary group of widgets that are children underneath the same transform.

Ideally when you want to anchor and animate something, you will either anchor it only partially (for example its corner, or 2 of the sides) and animate the rest. Either that, or simply anchor a UIWidget and place your animated item as a child of this widget.

[BeShifty]

Thanks for the reply. EnvelopContent just appears to be a beefed-up version of UIStretch, with a much higher performance cost if your hierarchy includes widgets you don't want to include (which is certainly a common workflow if you are taking advantage of NGUI's hierarchical fading). It's also located in Examples, indicating that it isn't a core feature unlike UIStretch. Lastly, it would be yet another script for our artists to become accustomed with, unlike the built in anchoring system.

I already addressed your second point in my example, and how they don't resolve this common issue. Anchoring a corner will not allow the "assembly" to slide while retaining its dimensions, and placing my animated items as children means they can't match the dimensions of the parent. Do you have any issues with my proposal specifically or do you just feel that the issue already has an acceptable solution (because it seems other customers don't)?

[ArenMook]

It's an example script, yes -- it shows you how it can be done. You can use it to create your own optimized version if you like.

UIAnchor/UIStretch, while "officially" deprecated, can still be used if you like. I won't be removing them as I've mentioned it before. So yes, what you are doing is fine if you like.

Keep in mind however... if you set your widget anchor to be executed only on Start, it will match your parent's dimensions once and afterwards you will be able to animate it freely. Likewise you could just clear the reference. That said, if you want it to match the size repeatedly and still adjust its position, then what you're doing is fine.