(!!!) Improving NGUI: Voice your opinion

[John.Bergman]

How about adding an event to the UIInput to handle the field loosing focus?  -- sort of a field changed event, but not for every character.

[John.Bergman]

Something else that would be helpful is an event when a component becomes visible.  either OnVisibilityChanged(bool isVisible) or OnActive(bool isActive).  This would allow components to trigger things like data load or refresh when the get hidden or shown.

[ArenMook]

@John: OnSelect (false) is just that. It's not limited to input fields. All objects have it. You can subscribe to it remotely using the UIEventListener.Add like any other event. As for onvisibilitychanged... why? OnEnable() do your logic.

[Rick74]

I'm currently using NGUI in conjunction with Smoothmoves.  Both create their own atlases but it would cut down on some texture memory if I could get NGUI to read other addon's atlases.

This is probably unrealistic, however.

Another issue I noticed, and I'm not sure if this is just a limitation of Unity or perhaps I just havn't found an answer to it, can game objects ever appear infront of a NGUI asset on screen?

[Rick74]

Oh and I'm probably a representation of allot of your customers who are artists first and trying to learn how to code.  As development teams are much MUCH smaller now for mobile games and portable devices. 

I found ALL your tutorials and videos VERY helpful.  I just wish there were more.  So my only suggestion is to keep making them!  Find some fun UI example from another game, and replicate it in a video tutorial.

As a beginner, I can't tell you how valuable these have been for me...rather then trying to look at scene examples and dig into each script to figure out what you've done.  Watching you build from scratch, using NGUI assets is such an easier way to learn and evolve as a beginner coder.

I guess I'm just more of a visual guy.   

[Nezabyte]

It would be great if NGUI scripts were in their own namespace; helps avoids conflicts with other assets.

[ArenMook]

@Nezabyte: NGUI in a namespace is not going to happen because as soon as I do that, all UIs become broken. When choosing between neat namespaces and backwards compatibility, I always lean toward backwards compatibility. Breaking everyone's existing projects to get namespaces is simply not worth it.

@Rick: Check the Useful Stuff sticky post, first reply.

[zippo227]

I avoid using  default values in function declarations. Which functions don't compile in monodevelop? If you tell me what they are, I can fix them. I use Visual Studio myself.

I definitely should have written down where the default parameters were, now I can't remember if it was 2.7.0 or 3.x.x. If I come across any, I will let you know.

I've decided to go bleeding edge and always take the newest updates. I think people should steer clear of 3.0.8 f4 and go straight to 3.0.8 f5. There was some weird stuff happening with my buttons that had UIPlayAnimation. You are probably aware of it, since you fixed it, but buttons with UIPlayAnimation were only playing that animation one time. I had a button that animated a window into view, but if I clicked that button again, it did not call the animation. Setting the trigger condition from OnClick to OnHover would work, but I needed it to work when clicking. Thanks for fixing, I thought that something had gone horribly wrong 

[indiefreaks]

I'm a real fan of your NGUIEditorTools helper methods as they help me a lot making my own custom widget and UI component inspectors. (NGUIEditorTools.DrawEvents() ftw ).

Unless I missed it in your code, I didn't find any helper method to draw Anchors as you do in the UIRectEditor class.
It would be great if you could put that into an helper method so we could use them.

[ArenMook]

Anchors are only drawn from UIRectEditor, as they only exist inside UIRect. I'm not sure why you would want them drawn from elsewhere? Are you using anchors in your own classes?

[indiefreaks]

Your anchor system works like a charm yet most of the time, you organize controls filling the space of the container being a window, a panel or whatever you might think of.
Thus, I feel easier to have at the container level an inspector that lets me tweak child UIWidgets' anchors seeing all of them.

I for instance am making a tile based UI using some sort of custom page system which gives you this current result (yet to be improved): http://www.youtube.com/watch?v=ifPZzEntFQ8

In order to organize my tiles for each page, I made a custom inspector that mimics (not totally) your UIRectEditor code looking for all the page tiles children and rendering in the Inspector the anchors. I can then adjust in the same place all the anchors for all these sub widgets in one single place without having to move my mouse from the Hierarchy window to the Inspector window then back to the Hierarchy window to select another one, and so on...

You made some great misknown tools in the NGUIEditorTools which I even use on my custom Monobehaviours. I even believe a video dedicated to developers willing to extend NGUI for their own purpose would be great

If you're not up to fulfill this request, I'll be fine, I made my way through my custom anchor inspector and even if it doesn't has all the features you provide with, it serves my current purpose

[ryan]

I'm also pretty excited about the new anchoring system, but it seems like you have to be careful not to go overboard with using them.  I did some profiling on an iPad 2 the other day, and on a screen that contained ~300 anchored widgets, it was spending a few milliseconds per frame in UIRect.Update.  None of the widgets were changing, but the overhead of checking the anchors (and yes, some overhead from the profiler) were taking a lot more time than expected.

I ended up removing most of the anchors, as they weren't entirely necessary for what I needed.  I had put them in so that everything would adjust correctly if a parent widget were resized, but in this case we weren't ever doing that at runtime.  I'm wondering if something could be implemented where changes to an anchor's target actively trigger an update down through the dependent UIRects, rather than everything passively reacting to target changes.  I guess there's a memory trade-off there to track the dependent anchors, but it might be something I end up implementing separately from NGUI if I have time later on.

[stapledon]

What are the chances of composite Alpha/transparency?

That is, similar to reducing the opacity of a Photoshop layer group; when you reduce the alpha of a group, it reduces the alpha of the contents combined, rather than compositing each alpha over layers below. This would greatly improve the quality of nested UI elements  (in particular, where there are overlapping edges) when in a semi-transparent state.

[amaranth]

I don't have time to check the eight pages of comments, but whether it has been mentioned or not, I would like to see a more intelligent text system that allows us to change font styles and colors for specific words, change the alignment of text per line, and most importantly, an easy way to embed images into our lines of text. Something similar to the HTML-style add-on system that someone created a while ago.

Another thing I would like to mention... Now that Unity 2D is here, I'd rather use the default 2D atlasing system that comes with Unity so that I don't have to use a different atlas for in-game sprites and UI sprites.

[ArenMook]

Unity 2D's atlassing system is completely useless in 4.3 as it's not available to be used properly by scripters.

Unity 4.5 is when it will finally be usable.