My Big List of Anchor Complaints

[makeshiftwings]

First let me start off by saying I love NGUI and have been using it for quite a while now, and appreciate all the work you've put into it ArenMook!  But in the interest of improving NGUI, I'd like to list some issues my team's having with the anchor system.  I'd also like to know if there is a chance that you will look into some of these issues and consider changing the anchor system, or if my whining is a lost cause and I should give up and switch to DF-GUI

1) Too much math.  No offense to my artist friends, but they don't like doing math in their heads, and neither do I to be honest.  If I want a button docked at (16,75) and it's 125x270 pixels, I currently have to do the math in my head to figure out that the right and bottom anchors need to be 141 and -195.  Ain't no one got time for that.  There needs to be a way to dock a widget and set its size like in most GUI designers.  I think the old anchor system was superior in this regard.

2) Anchors need to be completely divorced from the size of the game window in the editor.  I don't think anyone gets any benefit out of having their UI slide around when they widen the inspector to look at some random thing or resize Unity to look at their web browser.  And the fact that Anchors constantly overwrite the transforms of everything while in edit mode causes the scene to constantly need to be saved over and over and causes lots of bloat and annoyance with source control.  We should be able to set a default width and height for our UI that is consistent within the editor, and UI should only get stretched by the game window size when actually entering play mode, so that it is runtime only and doesn't overwrite the scene file.  I really need to know if this will change or if you are wed to the current system, because it's causing too many headaches.

I was going to whine more about anchors, but really those two are my biggest complaints; if I knew they were being addressed at some point it would put my mind at ease.

[sintua]

1) This is definitely an issue. A prime example is if I have a label that I want to sit next to a button. If I use advanced anchors to set the label's anchor left to the button's right, then suddenly the width of the label is no longer settable *despite* the fact there's no anchor right set. This also disables the resize freely, forcing the label to be a specific width (whatever it is before I set the left anchor).
I've mentioned it before, the dimensions of a widget should only be disabled if BOTH achors on that axis are used. anchoring to the right side shouldn't require me to anchor the left side to rightside+desired width, I should just be able to set the right anchor and set the dimension.x.

2) I think what you're looking for is Unity's fixed game view size, not changing how anchors work with window size. Anchors *should* adapt to whatever resolution you're using, as they do.
If you want to have a fixed window size, look at game view, in the top left you can set a fixed aspect ratio or resolution, then if you resize it won't change the ratio of the gui.
However, in the Scene view, it'll keep jumping back to some default value defined by who-knows-what. For example I have a background that stretches to fill UIRoot (fill screen), that keeps jumping to a 4:3 ratio in scene view and 16:9 in game view. which is somewhat annoying... if UIRoot looked at the Gameview dimensions as a reference when sizing the GUI that might stop?

[ArenMook]

@sintua first:

I just did a quick test:

1. New scene, ALT+SHIFT+S to make a sprite, ALT+SHIFT+L to add a label.
2. Moved the label, advanced anchor, set the Left side to be anchored to the sprite.

The label remains resizable. Nothing is ever grayed out. Even if I anchor it fully it remains resizable. Are you running some old version?

@makeshiftwings:

1. Why do this? Why not just move the sprite to where you want it to be and then anchor it? Why use numbers at all? If you want to fine-tune its placement, use arrow keys for nudging, just like in Photoshop, or hold CTRL to disable snapping to edges. Numbers are there for those who need them, but are certainly not necessary to create a layout.

2. A good UI tool should always be WYSIWYG. I never liked this feature of DF GUI where the editor would look one way then as soon as you hit Play, things change. It's inconsistent, and is a bad idea. As sintua mentioned, set a fixed size on the game view itself. This way everything will look as you will expect it to. Also, multiple monitors with the game view being on a separate monitor is a very useful thing to have.

The only issue I see is if the game view is hidden behind the scene view. This causes issues in Unity because Screen.width and Screen.height don't work properly anymore. It's a problem in Unity that I actually found a way around by adding a way to retrieve the game view's size without hacks and added to Unity prior to my departure from the company, but as with all Unity's features go it may be many months until it's actually live.

[sintua]

your response to @MakeShiftWings: thanks for clarifying about the game/scene view thing! I had my gave and scene view on top of each other, didn't realize having them both open keeps scene view from jerking about.

I'm running 3.4.9, though I don't see anything in 3.5.0 that would change this.

So I made a sprite and label, and as soon as I  anchor it the first "Dimensions" input grays out (pic1), so I need to disable anchoring, resize the sprite, and re-enable it to get the position, or as OP states, set the right anchor to the same target and add the offsets together for the offset amount.  It's not too terrible an inconvenience, really, but just seems like an oversight.

Also a small strange thing, are anchors supposed to take multiple "refreshes" to resize correctly? I put a sprite behind the label anchored to it, and changed the contents of the label. I have to grab the side of the scene view and "shake" it (resizing the scene view), and the elements (sprite anchored to label, label's anchor to the left sprite) will sort of shimmy back into place. It ends up correctly so this isn't really a problem, but might explain why getting the dimensions of anchored sprites sometimes returns unexpected values (that is, grabbing the value before the anchors have finished moving back into place).

For clarity: those label# pictures were taken with the Snipping Tool, and by taking a picture, clicking on unity to cause another "refresh" that moves the anchors a bit, then taking another picture, etc.
I also tried this with just the left sprite and label and it's the same thing, it takes a few refreshes for the label to slide back in place.

[makeshiftwings]

2) I think what you're looking for is Unity's fixed game view size, not changing how anchors work with window size. Anchors *should* adapt to whatever resolution you're using, as they do.
If you want to have a fixed window size, look at game view, in the top left you can set a fixed aspect ratio or resolution, then if you resize it won't change the ratio of the gui.
However, in the Scene view, it'll keep jumping back to some default value defined by who-knows-what. For example I have a background that stretches to fill UIRoot (fill screen), that keeps jumping to a 4:3 ratio in scene view and 16:9 in game view. which is somewhat annoying... if UIRoot looked at the Gameview dimensions as a reference when sizing the GUI that might stop?

I hadn't noticed you could set a resolution instead of just an aspect ration in the game view window.  That helps a little bit, but the anchors still constantly overwrite the scene if you touch any of the editor windows, which is half the problem.

@sintua first:

I just did a quick test:

1. New scene, ALT+SHIFT+S to make a sprite, ALT+SHIFT+L to add a label.
2. Moved the label, advanced anchor, set the Left side to be anchored to the sprite.

The label remains resizable. Nothing is ever grayed out. Even if I anchor it fully it remains resizable. Are you running some old version?

For me, it grays out the width as soon as you anchor either left or right, and grays out the height as soon as you anchor either top or bottom.  I'm using 3.4.9.

1. Why do this? Why not just move the sprite to where you want it to be and then anchor it? Why use numbers at all? If you want to fine-tune its placement, use arrow keys for nudging, just like in Photoshop, or hold CTRL to disable snapping to edges. Numbers are there for those who need them, but are certainly not necessary to create a layout.

Because sometimes we anchor the sprite but then realize we want to change the size, or we set the size and realize we want to change the anchor.  And we have to set the size manually by number to make it pixel-perfect since we have to use Fixed Size to stop everything from sliding all over the place when you move the play window.

2. A good UI tool should always be WYSIWYG. I never liked this feature of DF GUI where the editor would look one way then as soon as you hit Play, things change. It's inconsistent, and is a bad idea. As sintua mentioned, set a fixed size on the game view itself. This way everything will look as you will expect it to. Also, multiple monitors with the game view being on a separate monitor is a very useful thing to have.

It should be WYSIWYG in the scene view.  The scene view should not react to the inactive game window at all.  No other tool or asset I've ever used in Unity acts like that.  Unity is built around the idea that you do all your design in the scene view and then look at it in action in the game view, not the other way around.  Scene view should always take precedence when you're not in play mode.

Edit:  I wanted to add, I just want the OPTION of having a fixed width and height when designing the UI and to have it not overwrite the scene when moving editor windows.  If other people find the current behavior useful, then that's fine, there are already three options in UI Root to get the slidey behavior.  There could be one more for "ActualFixedSize" that actually fixes the size instead of just the height.

[ArenMook]

Regarding the grayed out dimensions: I misunderstood what you guys were talking about. The resize handles in the scene view are always interactable. The dimensions field in the inspector was getting grayed out, yes. I've changed it so that it won't be for the next version.

As a note, when anchoring things to only one side like that, I strongly advise changing the pivot of the widget to be on the same (anchored) side. Sintua, you're anchoring something to the left, yet the pivot remains centered. Change it to left as well. Also, you can force a scene view refresh by hitting CTRL+S to save it. No need to resize the game window.

@makeshiftwings: The scene view should not react to the inactive game window... what inactive game window? Are you hiding your game window behind the scene view like sintua? As I explained, this causes issues as there is no way to retrieve the proper dimensions of the game window if it's hidden. GUI layout should always use the game window's dimensions, never scene view's. Scene view is a "look behind the scenes". Game view is the one that should always have the true WYSYWIG representation, not the scene view. Why would you say it otherwise? If you design something in the scene view, then switch to the hidden game view, things won't look as you expect (especially if the game view is set to "maximize on play"). Can you imagine how many "BUG!" cries I would get on this forum if it worked like that?

[makeshiftwings]

I'm glad to hear the size fields will be editable soon; that will make our lives easier.  I still have to disagree that the game view window is supposed to represent the "true" look of the scene.  I see it as a quick way to test things while in the editor.  The "true" look is when you actually build the game and play it at the intended resolution.  That's why by default, the game view window is easy to resize and move around and in many of the default Unity layouts, it is sitting in a corner at a tiny resolution and weird, too-wide aspect ratio.  NGUI is also the only asset I've ever seen that alters the scene and overwrites your data based on how you move the game view window around in your editor layout.  To me, those things need to be totally separate.  My Unity layout and the size of the game window at any particular point have nothing at all to do with what I want anything in my game to actually look like.  Btw, by "inactive", I mean the game view when not in play mode.  I don't think the game view should have any effect on the scene in general (again, that's a Unity concept; in that all your changes while in play mode don't get saved back to the scene), but I especially don't think the game view should have any effect on the scene when you're not even in play mode.  In both games I'm working on, what's displaying in the game window when in edit mode doesn't really look at all like what the actual final game looks like.  The game view while in edit mode shows all components before they've had "Start" or "Awake" called on them, for example.  In one of my projects, the level is completely procedurally generated, which means while in edit mode the game view doesn't display much of anything, so it definitely doesn't represent the actual look of my game.  Setting the game view to a specific resolution helps a bit, in that NGUI moves things move around much less, but it's still not perfect because NGUI does still nudge things around a tiny bit any time I widen the inspector to look at something or (ironically) expand my scene view to work on the UI.  So it is constantly overwriting the prefabs in the scene with tiny floating point differences in UI transforms every time I touch anything.  I don't really think many people appreciate this "feature"; I see lots of people asking how to set a fixed width in the forums, or asking why NGUI keeps overwriting the scene, but I've never seen anyone say they really liked that resizing the game view window while in edit mode caused their UI to move all over the place in the scene view.  I just don't see the benefit that it gives anyone that outweighs the annoyances.

[ArenMook]

Set UIRoot to Fixed Size (height of your target device), and set the target Aspect Ratio on the Game View, and nothing will change as you resize your game view.

[makeshiftwings]

Set UIRoot to Fixed Size (height of your target device), and set the target Aspect Ratio on the Game View, and nothing will change as you resize your game view.

I tried that, and it mostly stays the same, but every anchor still overwrites the scene file with tiny insignificant changes to all the positions if I resize the game view.  It seems like it still recalculates every time I change the window and just gets a different value every time due to floating point rounding.  Ideally there should be a way to tell it to just ignore the game view window, by for example being able to set a fixed width instead of just a fixed height in the UI Root (not great but ok) or by being able to set a fixed "design" resolution that sticks in the scene view and then have the anchors reposition at runtime if it's a different resolution in play mode.  (This is what I'm used to with all other UI tools).

[Nezabyte]

..prior to my departure from the company, but as with all Unity's features go it may be many months until it's actually live.

Wow, wait a minute, you left the company? What does this mean for the future of the UI system they were building?

[ArenMook]

@makeshiftwings: Sounds like I should add some different float comparison logic in some places.

@Nezabyte: Nothing, I wasn't the only one working on it, and there are plenty of other highly skilled people to see it through.

[coeing]

@makeshiftwings: Sounds like I should add some different float comparison logic in some places.

@ArenMook: Have you had time already to look into this issue? I have those tiny little changes in the scene file as well only by loading and saving the scene. If it helps, these are the fields which change:

• Transform.LocalPosition, changes by < 1.0
• UIWidget.mHeight (Stretched to screen size), changes by +/-1 pixel

Looks like some floating point issue as you already mentioned.

[ArenMook]

If you give me a repro case I can look into it (just don't post the project here).

[coeing]

It's very easy to reproduce actually:

- New scene
- Created a NGUI 2D UI with NGUI -> Create -> 2D UI
- Created a widget under the UI Root with NGUI -> Create Widget
- Set Scaling Style of UIRoot to FixedSize and Manual Height to 1080
- Anchored Widget to UIRoot (Unified, OnUpdate, Left to Left, Right to Right, Top to Top, Bottom to Bottom, absolute offsets all 0)
- I have the scene and game view open. The game view is set to 1920x1080 resolution fix.
- If I now resize the game view (resolution still at 1920x1080), the local Y position of the widget transform changes as well as the height dimension of the UIWidget component.

I tried to debug the issue a bit and got till the NGUITools.GetSides (this Camera cam, float depth, Transform relativeTo) which gives different sides each time the game view is resized. Maybe this info helps with debugging

[ArenMook]

- If I now resize the game view (resolution still at 1920x1080), the local Y position of the widget transform changes as well as the height dimension of the UIWidget component.

I'm not seeing it. Position remains (0, 0, 0). Height remains 1080. Widget's width changes as aspect ratio changes, but that's to be expected.