NOTE: If this is available to read about somewhere and I missed it, please post links! 
To keep it simple, I’ll refer to the new system as uGUI2.
After watching the overview of the new UI system I (like most of you) got the feeling that things are finally getting organised and we are getting closer to having a true, built in, solution. However, there are a few important things that were not explained in detail (since this was only an “overview”), and some left out (?). I’ll go over them one by one, some of them reflecting about differences to NGUI (since the author of NGUI was a “helping hand” in the development of uGUI2).
Mainly there are some major flaws in NGUI that I hope have not infected uGUI2 (Note: I’m not trying to be a douche, NGUI is an okay product for a third party plugin, but comparing to say the iOS/Android-way of doing things it got some major design and feature-flaws which is what I hope won’t make it into uGUI2).
The arguing going on below is IF it is the way I hope it’s not. So if I’m wrong, I’d be more than glad to know!
The “anchor system”:
Now, just the name “anchor” gives me shivers down my neck, since this sounds and looks a lot like the anchor system implemented in NGUI. That is, for me, horrible news. Not sure how to explain this in a few lines, but I’d really like a more thorough explanation (like, where are all the input values?). If I want it to half the width of another rects width, where do I input “0.5”? And if I want it to be 50% of the width + 10px, where do I input the +10 constant?). There is a mystical anchors-array visible in the video, however it is never folded out… What possible values can be altered manually? Seriously, dragging around anchors is a very bad practise for more than just “close enough”, temporary, placement.
Most importantly about this anchor system: How does it compare to a REAL constraint system? A constraint system is so basic at it’s core, and gives so much flexibility (and is very logical to think about). After using NGUI’s anchor system for a day it just felt extremely hacked in and with loads of special-cases (just looking at all the if-statements and every-frame-updates made my heart hurt). Basically constraints work by taking one property-value from rectA (say left), run it through a linear equation, and output the new value to some property on rectB (say right). Now with a very basic, logical and readable equation rectB is placed with right edge to rectA’s left edge with some easy to manipulate values. The equation is just outputValue = inputvalue * multiplier * constant (never seen that before!). Read here to get a better understanding of how apple does it. This is what I created myself for NGUI, and the speed at which you can get content in and have it automatically & smoothly handle different resolutions is… a lifesaver.
Talking about Rect Transform, what events can be expected? Not talking about the hardcoded messages (OnColliderTriggerWhatever) but actual callbacks that can be registered to to notice changes in size etc.? And a followup questions that I was actually leaning at: Is the anchor system event-based or updated every frame?
Answer: “It’s event-based.”
Edit.
In the video I saw no way of determining which object to anchor to (parent was default). Is it possible to set this manually? (Expecting the answer to be yes of course, just checking!)
Property Binding:
Property binding is one of the most essential components of a flexible and easy-to-use UI framework, but nothing was unveiled in the video about this… Is this implemented of some sort, or have it been overlooked? I wrote a very handy binding system for iOS once. It allowed you to, with just a small line of code, to hook up one property of some sourceObject to a property on another targetObject (with the ability to choose direction). No pulling, no expensive checking, just event-based binding. Think MVVM.
Ideally it should be possible to do it nicely in the inspector (just exposing some property through code, being the “source”, and then hook it up to different “targets”/widgets which will update automatically.).
- Value Converters:
This is part of the property binding and MVVM.
Value converters are a very clean and handy way to “puzzle up” none-matching values (eg. a boolean converted into some usable int value). It’s extremely flexible, and conforms to the “open/closed” principle. You’ll avoid the need to add custom stuff to others code that will be replaced in a future update (which is a stronghold you never want to get into).
Empty view/widget:
Looking over the list of possible UI components, I didn’t see an empty, “invisible”, view. Setting up UI is not always about sprites and labels, but a lot of the setup consists of positioning, grouping and encapsulating objects to setup a logical hierarchy. Of course there is some core base-component representing a single view. Is this “Rect Transform”? Anyways, it should definitely be available in the UI-menu.
Clipping subviews:
IF Unity was smart enough to make a core component representing a single view (no graphics, just the logic behind a frame etc.), there should really be the possibility to chose “ClipSubviews = true/false”, meaning that if a childView (say an image) is moved outside the bounds of the parentView, it will be clipped/culled. Now, I saw the masking ability but again, this is a core feature and should really be an option on all UI components (deriving from the core “view”-component).
Aspect/Content Mode:
This really just means the possibility to determine how the content of a view is laid out, think about an image for sake of argument. The ImageView is the UI component dragged around and determines the bounds, position etc. The “Image” is the rendered content inside the ImageView. The most common is: Fill, Aspect Fill & Aspect Fit.
- Fill: Stretch the image.
- Aspect Fill: Stretch the image until the bounds of the view are fully covered, still maintaining the aspect ratio of the raw image. This is where “ClipSubviews” comes in.
- Aspect Fit: Stretch the image until the first edges touch, making the image fit into the bounds and still maintain ratio. If the ratio differs from the bounds, there will be an empty border (think you get the point).
That is some of the things I had on my mind! Feel free to comment, but add the correct headline from the corresponding part so it’s easy to follow up!
Cheers!
