Ok, i take the time to give some long feedback, too.
Now i say it upfront, this is not intended to be a bashing of NGUI, NGUI came in a time where there were only way worse gui options in unity and most people still relied on using ongui or building their own gui solution from scratch.
Ongui lead to too many drawcalls (hence bad performance on mobile devices of back then), no multitouch support and no way to create anything in visual workflow in the ide.
So NGUI addressed all those downsides and was also way better than all the other offerings back then and we used NGUI in many projects successfully and that was a big gain for us so i'm thankful for that =)
It also allows to do 2D and 3D UIs and combine them, animate them in both 2D and 3D etc, which still today not many others do that well.
Now comes the "But" or to name it positively improvement suggestions =) Both for NGUI and also possibly new future Unity builtin gui, listing things which are lacking and should be added or improved:
Over the course of using NGUI for many projects, time and time again i stumble over the same limitations on a few ends which make some things way more cumbersome and time intensive to do than they should be.
I catch myself fighting against the same type of limitations and adding the same kind of workarounds and extensions over and over and at the same time having to redo way too much because things are not well portable between different projects, scenes or atlases.
I'll list the major ones of those and for some also how i think those should/could be addressed:
-In NGUI one has to build together scrollable textfields, scrollable lists and two directional scrollpanes together by hand out of various components/scripts. Even more basic controls like buttons, checkboxes/toggles, dropdown menus etc, all has to be handmade from several parts/components/sprites.
It is good one can build together all parts of things when wanted, but no good that there's no built together ready to use scrollpane control or button control or checkbox control for example which one could just drop in and use, just choose the sprites used for the parts, the font and be done with it, or stick with the ones used by default thanks to the builtin controls coming with builtin atlas images (which merge to your atlas).
Since there's nothing like that, this also leads to various other issues like way too cluttered gameObject/component hierarchy and numerous additional depth sorting complexities issues cause instead of say one gameobject with a scrollpane controller attached to it one already has many nested gameobjects with scripts and depth sorting issues items on them to get a scrollpane going.
-same goes for having to build together any other control like a checkbox or button. Again, nice one can build one together out of several sprites and scripts and gameobjects etc, but yeah, there should also be a ready to use checkbox and button etc control which i can just add in and it comes with default sprite for checkmark and bg and label and i can switch that to something else and be done with it.
-that also goes for things like a scrollable list, there should be a scrollable list control which one just drags into the scene, it has in the inspector a default list item (icon and label highlightable toggle button like list item) prefab builtin ngui list item pre selected and one can edit or replace it. And there should be several premade builtin list items for the standard things (toggle button with bg, highlighted bg/color, icon and label, or datagrid list with multiple labels and sortable on headers)
For these premade UI controls (a full checkbox a full button, a full scrollable list, a full scrollpane etc) there should be a GUI skin which by default uses a builtin atlas and then one can just for the parts they use (like a label, button bg sprite etc, scrollbar thumb sprite etc) choose a fitting image from the atlas one has and they all look right then.
One could further improve reusability of atlases, skins and controls by extending the atlas system so that there is always a spot/name for the images of the builtin controls' used atlas images (like a panel bg, button bg, scrollbar bg, scrollbar thumb, default font etc).
Right now stuff we create in NGUI is only really reusable to the degree where we do something with the same atlas in same look in another project. Otherwise stuff made in one project is completely unreusable in another project cause one has to make all those controls from scratch again and it is tricky to change to which atlas/camera etc a control belongs and which images it should use etc without changing all those things by hand for each separate part of a control.
i bought a few ngui controls packages from the asset store for example and really, besides showing to a newbie how to set up things in ngui or if one wants to use those controls with exactly that atlas/ skin, they are basically useless in another project, cause of the way how cumbersome it is to replace just which atlas/images are used for the different controls parts.
A basic example: In the sample scenes coming with ngui there are different atlases used for different scenes.
Just try to copy let's say gameobjects from the scrolling list example scene with wood atlas to one of the scenes with sci fi atlas and try to get those two using the same atlas and work fine together there.
Very Painful, time consuming and tedious.
What should happen is: I paste a scrollpane control from the other scene into this scene, it recognizes i used an atlas/skin which is not used in this scene, it asks me if keep this skin of the pasted items or replace with one of the skins used by the items in this scene and blamo, all components look fine, use the same atlas and work with the right camera etc.
If on top as i suggested each atlas automatically has slots for the images of parts of builtin controls like builtinControlScrollBarThumbImage then it would automatically use the right image from the other atlas.
And since the scrollpane has for example exposed a field for scrollbarbg, scrollbarpane,scrollcontentbg, scrollcontentframe, i could either just replace those sprites or if my other atlas has items with that same name (which then all atlases should have by default for all builtin controls and the parts textures they use) then it would just use those.
So basically ngui should get a guiskin skinning model like OnGUI has it for the standard controls and their part sprites/labels.
add standard control (button, toggle, checkbox, scrollpane, datagrid etc) to a scene
—>the atlas would get sprites added from a builtin ngui atlas for all those parts those standard controls use like standardControlScrollbarThumb. If an atlas in this scene already has sprites of that name it would ask if one wants to choose those or replace them.
Huge gain in reusability, portability, quick skinning ability etc.
Ok, onto another big issue: using certain relative screen dimensions.
NGUI has anchoring covered and stretching of items covered to certain extend. But what should be possible would be one can place a container rectangle on the screen (and premade controls like a scrollpane contain that, too) where one can stretch/resize the control and toggle an option to set keep relative screen dimensions and then the control automatically uses that relative screen size.
so let's say i use a scrollpane which starts at x 110 y half screen height and then fills up half the screen height, then when the screen is twice the height it should still start (procentually relatively) where it did and cover half the screen height.
Right now its too cumbersome to make a control made out of lots of components, like a scrollpane, cover a certain relative screen percentage and make it always cover that certain relative screen dimensions and adopt to different resolutons/screen dimensions.
One should be able to set for x/y/z, width/height of a control if it should keep that position absolut (actual pixel values) or relative (screen percentage) when screen size changes.
-masked/clipped areas: One should be able to set the dimensions of those with a rectangle and that should have its offset anchor on the top left, not set up in a way where one has to put it in the center and then stretch in both directions. Same goes for hit areas. Hit areas should also by default cover the bounding shape of the whole control (when not toggling off that option it should resize automatically as one changes sprites etc used in the control or the dimensions of the whole control)
-text is never satisfying to me in ngui: either not sharp at different dimensions with bitmap fonts or depth sorting issues when using usual fonts since then basically the rest of ngui and those fonts don't play in the same depth sorting worlds properly.
-a better way to handle how to react to different resolutions and ppi, be able to set as general default and per control how to react to different resolutions/ppi. Really keep the same actual screen size dimensions for a control on per control level decidable or scale relative to the screen res/ppi.
-bad list performance:
using tiled sprites and images not part of an atlas (UITexture) as list items in scrollable lists is an extremely performance intensive thing since it leads to high polycounts and extra drawcalls,and lists with many list items aren't a great idea in general cause it still always handles all list items which are not in view/clipped.
Something like that should be improved, too, like for a list item when i set a tiled sprite or gameobject (with numerous sprites etc) as bg, it should give the option to add that as extra sprite so then it would make a bitmap image clone of that bg as it shows and add it to the atlas so then only using that one larger image as two tris rectangle instead of at runtime having that rectangle made up of many rectangles in small size with many tris.
This would also address another issue for containers with many items which is it then moans too many vertices and can't display it in same panel anymore with same clipping area anymore.
If i know my list item bg which is used for all list items will always have the same dimensions and use the same tiled sprite, why not just add the whole computed thing to the atlas so it uses two tris in a rectangle with that bg as one atlas element instead.
In lists it also shouldn't always handle all elements, it should allow dissabling/not drawing those outside the clipping area. Even more ideally it should on visual side only create enough list items to fill the clipping range+2 and then reuse those when one scrolls by changing their label or other per item changing content.
-there should be anchors for anchoring relative position within containers
-there should be tab focus switch between controls
-there should be supply psd and choose where the sprites are in that
-no kerning, line spacing and generally too few text controling features. what about set a label to autosizize left, right etc, scale to fit only in one direction, get the dimensions of a label easily
(easy as in label.textWidth), copy and paste in textfields, drag select text etc
-the new custom transform handles are bad and should go or at least they should always be behind the usual transform move tool handles so one can still use them
-i won’t even go in detail into what would be the next major and great step after all those: being able to design vector graphic ui control’s parts (like a bg or similar) inside unity and have the option to have that added to the atlas (next to it storing the vector points/fill info internally for editing again later on) or rasterize it at runtime.
So really, it would help a lot already if it came with builtin atlas/skin for standard controls, some standard controls and an easy way to replace those standard controls atlas images/skin and use em/combine em/replace em in own projects and then take it from there with those other things i and others listed.
