Tasharen Entertainment Forum

Support => NGUI 3 Support => Topic started by: ArenMook on November 13, 2013, 05:15:44 AM

Title: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 13, 2013, 05:15:44 AM
As some of you may know, I created NGUI 2 years ago for myself because I needed a UI system. Since then it has grown and evolved over the first year, but then I joined Unity and the development slowed down. That was in part because of my contract with Unity which allowed for only minor changes to NGUI, and in part because I was too busy with support and the new full-time job at Unity.

This is now changing, and as many of you also know, a new UI that I've been contributing to at Unity is coming soon... but it's still based off of NGUI, and my view of what's important is biased because of that. And so I turn to you, the users. What's important to you? What would you like to see in both NGUI and/or Unity's GUI?

Some mentioned contextual menus in the editor. I've done a first pass on that recently by adding a way to right-click on widgets in order to show the hierarchy of what's underneath. Do you want to see more options there, or do you worry that it will be cluttered and unusable? An example would be the ability to create widgets from the context menu, add child objects, attach common components... To me that seems redundant since NGUI has hotkeys for that (ALT+SHIFT+S to add a sprite, ALT+SHIFT+L to add a label, T for texture, C for collider, etc). What do you think?

Also, which areas do you want improved / redesigned? The anchor / stretch system redesign is already on the roadmap. More intuitive way of specifying clipped regions is as well, and will come before the anchor/stretch system. What else? I know the lego-like structure of NGUI's widgets does not appeal to everyone and some find it complicated (checkbox being several game objects / components for example), while others like the fact that it's flexible and offers a way to customize their UI without modifying code. What about you?

More importantly still... what frustrates you in NGUI? What makes you go "AAAARRRGHGHHHH!!"? I myself tend to rage quite a bit IRL (mainly related to Mecanim lately... ugh!), so I am quite guilty of hating the system because I don't understand it. So if something is driving you nuts and you want it changed / explained, feel free to vent here and I will do my best to do something about it.

So, in short -- I want to improve both NGUI and uGUI, and your opinions can do just that. :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: zasadnyy on November 13, 2013, 05:43:08 AM
Hello,

One thing that frustrates me - is how pixel perfect / fixed mode on UIRoot works, before game dev I was an android developer, and their approach of specifying dimensions in dip's (destiny independent pixels) is much more easier to understand and work with, as for me this could be cool improvement (or as an option, maybe some tutorial with best practices how to make ui for different resolutions). Also together with previous idea it would be nice to have automatic atlas switching (for different resolutions) out of the box.

According things you've mentioned, as for me - contextual menus in editor are overhead, shortcuts are more comfortable to work with, lego structure of components - is not a problem at all.

p.s. can't wait for improved clipping system:)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Skjalg on November 13, 2013, 09:09:29 AM
First of all, I think you're selling yourself short on the development slow down. I think you have prioritized fixing some of your early mistakes and that has benefited all your users. (Not being able to nest was my biggest gripe with NGUI before).

Right now I feel like I can do most things with NGUI, except optimize it for all my use cases. I'm not sure what the anchor / stretch system redesign will entail but I hope it will focus on getting rid of the reliance on Update methods. There shouldn't be any reason for GUI to update every frame unless it is tweened. UIGrid should be updated to the standards of the other widgets - It should contain pivot, size and reverse direction. Kind of like a label in that regard.

Recently used Assets (for selecting atlas and font) is just tedious to work with, because I don't trust it. It is not always updated and so I don't want things to break so I manually find them myself instead. Theres a little circle to the right of an Object field, but for some weird reason this doesn't work. Make that work instead of having to rely on a custom editor to locate your assets.

I think NGUI options should move over to Edit/Preferences and then have an NGUI tab there. It would be handy to be able to toggle features on and off etc.
http://docs.unity3d.com/Documentation/ScriptReference/PreferenceItem.html

The Atlas Maker needs an overhaul. Or maybe you can just support the new sprite system that came with the 2D update? Anyways, right now theres several issues with how it works. The "Save/Update Atlas" button should be the only button that updates the atlas. Creating a new atlas should prompt you with a save dialog instead of creating the atlas in what seems like a random folder. Adding textures to your atlas should be done with drag and drop from the Project View (or context menu). But the atlas should not be updated until you press save/update. You should also be able to see the textures in the atlas maker, like you do when you select a sprite. Deleting textures from the atlas should happen when you press the x, but it shouldn't be updated to the atlas until you press save/update.

It would be handy to have a some more context menus in the Project. Like when I have selected a textAsset and TextureAsset I should get the option to Create->Font which launches the font maker. Also when you select a texture and right click you should be able to add to -> and then get a list of all atlases in your Project. This would then open the Atlas Maker.

I also feel like how to support different resolution sizes could be made smoother. It makes sense that I have to create a font that I call "Header Font" which is a reference to "Header Font SD" and "Header Font HD", but right now the references can quickly become many and its not easy to maintain which is which.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: broken on November 13, 2013, 09:13:53 AM
With regards to opportunities, we would like to see a lot of that is in the Flex in Flash (eg layout system) :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: sisso on November 13, 2013, 12:02:40 PM
I personally think that NGUI is still developing fast and I am very happy with the tool.

If you really is need something to work (hehe). The only difficult that I have today (wilth simples workarounds) are merge game inputs with ngui inputs (sometimes I need a isHot method or GetAllTouches()), allow a better integration with 3d models, to use in drag panels for example (today I use fake sprites :P).
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ant on November 13, 2013, 12:35:07 PM
Ability to use 3D assets (models) to build UI then embed into NGUI's containers.
Creating 3D UI fails because lacking of depth-peeling (Order of Transparency) support.
Could NGUI do something as a workaround?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Quarkism on November 13, 2013, 01:33:31 PM
Easy Conversion to the new UI. I would appreciate it if you slowly start moving us to the new programming model so that when the time comes to switch most / all of the work can already be done to convert my project over. For instance with Unity 4.3 released a version of NGUI that utilized the new 2d sprite system would be nice.

A second (lesser) point would be a reactive layout system. Reactive layouts are wildly used in web program (see Bootstrap as an example) to have a single UI render differently depending on the screen size. For the most part row cells stack horizontally when the screen is large.. and collapse into a vertical arrangement when the screen is small. Such a system would be very beneficial to unity as it is (like the web) cross platform.

A third (lesser) point would be to html rendering.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 13, 2013, 03:03:55 PM
Tool that does conversion to the upcoming UI system is pretty much a guaranteed feature at this point. I've done two prototypes now with various degrees of success. One doing the changes directly by converting all existing sprites to a new system, and another tool that saves the entire UI into a text format that it can also be read from. There are two unresolved issues at this point. First is that Unity doesn't seem to expose a way to get the object's GUID, and since scripts and other components are referenced by GUIDs, there is no way to preserve references such as fonts on labels when saving into the text format. Direct conversion makes this easier, but since the new UI system uses UnityEngine.Sprites, and NGUI uses atlases that have no reference to original textures, auto-conversion is somewhat... difficult. There needs to be some place to specify which sprite maps to which texture, basically. These two issues are the main reason why the Pro repository doesn't already have this tool finished for the Unity Alpha users to play with.

Layout system in NGUI is another thing I've already started re-thinking. Unity GUI is already getting a completely different layouting system (no more anchors / stretch scripts, yay!) thanks to one of our devs who had an awesome idea (Rune (http://blogs.unity3d.com/author/rune/)).

HTML rendering falls into the same category as rich text rendering. Labels have needed a lot of love ever since the dynamic font implementation, and it's definitely something I plan on doing in the near future.

@ant: You can create 3D UIs just fine as long as you separate the elements you want into different draw calls by adding extra UIPanels. For example if you wanted to have one UI element refract another element that's below it, simply draw them using different panels (and make sure the panels have different depth values).

@sisso: Unity's upcoming GUI system comes with an event system that does input handling quite elegantly. I'd still want it to improve a bit and have a way to subscribe to specific events (specific key being pressed) instead of having to poll them using Input.GetKey every frame though... We'll see if I get the time. Keyboard and controller handling / navigation within NGUI is another thing that I've never expanded on as much as I could have and have been meaning to do but never got around to. I did it nicely in uGUI though.

@Skjalg: Unfortunately most of what you mentioned is this way because of Unity. For example, it not being able to see any atlases in the scene when you click on the atlas button and/or the round button to its right. That's Unity being... Unity. Context sensitive menus on project assets is an interesting idea though. I will see if it can be done.

Thanks for the feedback so far guys, keep it coming!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: TegTap on November 13, 2013, 03:54:37 PM
I love the fact that it's flexible and offers a way to customize their UI without modifying code.  I don't mind a lot of game objects. 

Maybe there's something I'm doing wrong, but it seems that whenever I create a new UI root, the scale is always really small and I can't change it.  Granted, this doesn't affect functionality much since all of the UI is relative to that parent UI root, but I sometimes copy/use elements outside of the UI root hierarchy, so it would be nice to either have that scale default to 1,1,1 or be able to manually change it.  Thanks for maintaining a great product.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 13, 2013, 03:58:11 PM
UIRoot is always scaled to 2 / height, where height is manual height if it's fixed size, and screen height if it's not. It's done this way so that the UI is not massive on your screen compared to other objects. You can disable UIRoot and you will then be able to scale it, or just set the manual height of UIRoot to 1. Just be prepared to adjust your camera's size from 1 to your target screen height.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: gdeglin on November 13, 2013, 03:58:41 PM
Thanks for all the great work so far! Here are some things that I would really love to see:

1. Sprite dicing - 2D Toolkit has this feature and it's amazing. It cuts your sprites into little pieces (you can specify the size), then removes duplicates and transparent pieces. This results in significantly smaller atlas sizes. It also reconstructs the sprites in the game onto a mesh that doesn't include the areas where the transparent pieces were, thereby significantly reducing overdraw.

2. Parameters in callbacks. - The new callback system is great, but would be even better if it let me specify parameters and values that would get passed to the callback.

3. Anything to reduce memory allocation - Right now NGUI cameras seem to allocate a bit of memory on every frame. Roughly twice as much as regular cameras. Anything to improve this or other areas where memory can be allocated would be really useful.

4. Improved sprite atlas management -- NGUI's atlas maker is very bare bones. Along with dicing (as mentioned in #1), it would be great to see the following features:
A: Per sprite materials
B: Sprite previews in the window
C: Automatic multiple-resolution altas generation

5. Built in support for multiple resolution textures (based on device). The textures should get loaded from resources or an asset bundle so that unused ones don't take up memory.

6. PNG atlas support
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 13, 2013, 04:01:19 PM
To get a preview of a sprite in the atlas maker, just click on its name.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: dillrye on November 13, 2013, 05:40:20 PM
I would love to see some more layout focused updates, such as the ability to add margins to an element so when it is put inside a container such as a table, it would not directly but up against the previous element, or the ability to order items.  Our application currently does a lot of non typical game UI layouts with NGUI, its more or less creating web layouts that need to have flowing elements.  UITable/UIGrid somewhat supports this, but we end up positioning a lot of items by hand(math!) to get the desired effects.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: motionsmith on November 13, 2013, 06:51:08 PM
Thanks for asking!

There are some things that are keeping me from upgrading from 2.x to 3.x:


As for new features:

NGUI needs to make it easier to work in device-independent pixels like Android (dp) and iOS (points) do. This includes the tedium of loading the proper resolution atlases

A layout system. It should make it easier to scale components based on the size of the screen (again, in "dips", not pixels), and support "containers" that scale to the size of their contents.

Additional scroll panel features: 1) A content "offset" padding from the edges of the scroll panel, so that when the content "springs" back, it springs back to a padded offset point, rather than hugging the edge. 2) Support for nested scroll panels, so that a child scroll panel can scroll horizontally inside of a vertically scrolling parent.

Ellipses for truncated labels!!!!

Great work. I appreciate all the hard work and support that you give (I did it for years with the Flash Game Engine, Citrus Engine (http://citrusengine.com)) so I know how maddening it is.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ikuniojp on November 13, 2013, 09:40:11 PM
My company has bought only 3 license and planing to buy more if we can figure out how and why thing works the way they are in NGUI.
I know you do not have time to read so I will keep it in point to point note.
I am still new to NGUI so please be patience if I sound noob.

Need:
1. Panel Manager (Like scenes in build settings but for panel)
2. Better Depth Manager (If possible auto Depth distributor in specific number address by user)

Want:
1. Ability to specify which UISprite to stay on load next scene (Do Not Destroy On Load)
2. Have toggle button still working after hide, (Ability to specify which UISprite to not remove from better list)

Pie in the sky:
1. Auto sort multiple Atlas in folders (automatically copy only the used images, create new folder with atlas name, put all the used resource in that folder).
2. Undo in Atlas, (Sometimes Add new items to atlas still reset the dimensions of the sprite? Ver 3.0.5)
3. Panel Transition, Fade in(out), Zoom in(Out) ETC (Maybe in Panel Manager?)

My 2yen ;)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ikuniojp on November 13, 2013, 09:45:44 PM
To get a preview of a sprite in the atlas maker, just click on its name.
Sometimes, It's hard to click on one by one to find an image.
It's even harder if you have hundreds of files created by a teams of people.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: breakmachine on November 14, 2013, 04:08:36 AM
1. Less memory allocation.

2. Depth tools.
Maybe something like the panel tool but for widgets?

3. More delegates/events.
Would be easier to extend if you want to apply actions after certain events such as when grid has been re-positioned, a label has been populated by UILocalize or when UIDraggablePanel has started dragging.

4. Combining the above with the new callback system.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 14, 2013, 04:32:38 AM
Undo in atlas... how about a preview instead? You click the "add" button and it shows you the "before" and "after" atlas textures. You can then hit Apply, and changes get applied, or Cancel to ... well, cancel. :)

Depth/panel tool: Nicki actually made one a while back, it's in the useful stuff sticky. I can certainly make something similar, but I'd prefer to have a better way to go about it so that using that tool is not necessary. Still thinking on the matter...

More delegates/events: you just reminded me to finish something I totally forgot about. I love this thread. Thanks guys, keep 'em coming!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: BGL on November 14, 2013, 04:34:37 AM
First of all, thanks for your work and your support.
Here my wishlist:
New "WOW!" features
Improvements
Code Improvements
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: hitorijanai on November 14, 2013, 05:16:20 AM
Wow cool! Please make source code structure more extensible by providing more virtual methods. I hope this way we can preserve our own hacks or customization when upgrading NGUI to newer version.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: tra on November 14, 2013, 09:26:07 AM
How about indie Unity 4.3 where batching on new sprites do not work?
Currently with NGUI atlassing we can build atlases even in indie version of Unity.
Will there be two branches with native atlasing for pro users and custom atlasing for indie?
or indie will stay with old ngui...

regards, tra
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Malzbier on November 14, 2013, 11:28:08 AM
For me at the moment the bigges issues are the anchor / stretch system (Extended my own versions) and the Depth ordering is making me going crazy.
If i have to set the offset of the UIAnchor to -50 after changing the font to make it re-appear ... that total wrong.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: DarthMH on November 14, 2013, 11:51:46 AM
Improvements to UILocalize as:
In my view, the UILocalize, has been sidelined in the latest updates.
---------------------
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 14, 2013, 01:11:32 PM
Pro version of NGUI already allows you to create gradients on labels, and I've considered doing that for sprites as well. Perhaps I should? Preview of localization data in inspector a good idea. Most people don't even think about the localization system. I haven't given it much thought in a while.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jeldrez on November 14, 2013, 01:34:32 PM
Improvements to UILocalize as:
  • Native support to CSV file
  • Letting you select an item from the translation file using a dropdown, in UILocalize component.
In my view, the UILocalize, has been sidelined in the latest updates.
---------------------
  • Allow create grandient color (first and last color) components.
  • More rich text content in labels

This ones above are really cool and useful. I also support the idea of Data Binding.

Currently I have some concerns about:
- How it works ActiveAnimation, it's missing a blend mode to play more than one animation from the same Animation object. I used to use it a lot, until I figure it out this and then I started using
- UIDrawCall, I don't know why, but sometimes when I create some UIPanels the images inside never dissapear from the editor. [I posted this in another topic (http://www.tasharen.com/forum/index.php?topic=4293.msg27352#msg27352)]


These is what I have for now. Thanks Aren for listen to us.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 14, 2013, 01:55:45 PM
Data binding has already been prototyped, and the Pro version has some testing code in it that has the framework for it. I'm still not entirely sure I understand what's the best use case for it. I use it to be able to set both properties and values of a remote script by name -- which, while cool, seems like a strange way of going about it, since I can just do a GetComponent and set the value directly. I can think of a couple semi-useful use cases, but I'd like to hear what you guys would use it for?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: DarthMH on November 14, 2013, 02:43:03 PM
Pro version of NGUI already allows you to create gradients on labels, and I've considered doing that for sprites as well. Perhaps I should? Preview of localization data in inspector a good idea. Most people don't even think about the localization system. I haven't given it much thought in a while.
I like NGUI Localization, easy to use and very well integrated. One more point that makes me not using it is the lack of support to a CSV (so I could keep two or more languages ​​in a single file) and GoogleDocs (but GDocs support is not required, but it is only a facility.)
But I want to continue using it, I think an update with more interactions, it would be very good.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: armitage1982 on November 14, 2013, 03:41:38 PM
Text Selection
Normally it's the first thing I'm looking at to see how robust and evolved a GUI is. Would probably allow us to write a few applications/editors rather than just games.

Also
Severely thing about publishing a comparison table on your website as soon as the new Unity UI is out, whether or not it's useful to keep both, how exactly they can mix together if it's the case.
That figure is currently happening to 2D Toolkit / Unity 2D tools and (while I'm angry because I could have bough it now for 1/4 of the original price) I don't exactly know if mixing both of them is performances & features wise nor *so* interesting.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: haueryou26 on November 14, 2013, 07:10:34 PM
Hey Guys,

First of all I love the product and I have been crossing my fingers for a updated tools for Packing textures within Unity.  Specifically having the ability to pack them into the individual channels of a single texture, aka R,G,B.  Is there any plan to support this kind of functionality?  I know you already have a shader that does this for text you author in an external program.  Unfortunately I cant find a solution to this for UI images.  I have tried to do this process by hand but messed up the code portion of the operation and when i associated the shader it was a hideous mess.  Can someone tell me if there is a reason NOT to author content this way?  I'm working on a mobile game and memory is my big issue right now and figured if I could drop my UI Atlas from 2x2048s to 2x1024s that alone would be a HUGE WIN!  If you don't have plans to do this I suggest stop reading from this point on because its me just explaining how i could see it working in unity.

Tool suggest workflow.  So I think the way your Atlas tool works right now is perfect you would only need to add an additional field that would allow me to tag what atlases i would want to pack into a single texture and which channel each would be associated with.  For example: I have texture 1. o with my Fonts, Texture 2. with UI element, and Texture 3. with more UI elements.  All of these were created using the already existing Atlas creation tool in NGUI.  All fonts and UI are grey scale or Black and white so they can easily be packed into a single channel and you wouldn't lose any information.  You then only need to have an Atlas, Packer that you can drag each into a slot that represents the R,G,B and the choice of the A channel.  Once these textures are associated and processed you then hit a button and a single texture is created with updated text file with the corresponding placement of all the UI,Text elements so the shader will know each association.

That is it!!! Not to make this sound like trivial work because I'm sure it is not. You would have 4 times the texture space in a single texture.  The only limited factor is that you would need to create a few more shaders that allow you to change font and UI color.  This would be a few more draw calls but the amount of memory you would save would be huge.  Any thoughts on this?  It is possible you can already do this and I just happened have missed this update.

I hope I was able to clear up an questions and concerns on this.
-Stephen Hauer
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: joeleaver on November 14, 2013, 07:36:11 PM
I'd like to put in my vote about improved UIInput text selection. It could use a better, non-character-based caret, shift+arrows to select, mouse drag to select, cross-platform clipboard support, ctrl-arrows to move by words, etc. A big part of my work right now is building an in-game level editor.

Data binding would be awesome, but I'm not sure how much use it would have on the primitive widgets themselves. As you say, databinding to a label isn't that interesting. But having a lookup list or combo box or tree that is databound to an array or a dictionary is awesome, but I wonder if it's within the scope of what NGUI is trying to provide. It seems like NGUI is more focused on being a foundation for building UI widgets out of primitives more than it tries to be an entire GUI out of the box, which is totally fine.

There are a few more-complex widgets that I use frequently: dialog, modal window, messagebox, navbar/menu, tab group, tree, combobox, scrolling list box, tooltip, file browser window, all of which I've implemented to some degree with NGUI primitives. (A real tree widget is a massive undertaking.) What's fun about that is that if I ever get one complete enough, I could sell it on the asset store. It'd be awesome if there was some sort of published standard or best practices to follow when developing a re-usable complex widget. I'm not sure how that'd work, exactly. Kind of like how there's a massive add-on community around jquery, and you can find jquery-based widgets for almost anything. I'd like to see (and develop!) NGUI-based reusuable widgets. Anything the code base could do (and I have no idea what that might be) to make that easier to develop or share, that'd be awesome. Maybe a "theme" specification: a standardized set of named sprites for window decoration and UI-element pieces? Or maybe not. I love the current flexibility, too.

About the only thing I've ever really gotten hung up on was trying to make a draggable window with a variable-size scrolling list stay constrained within the screen. The size of the invisible scrolling list changed the size of the bounds of the window, and made for some odd results. The easy workaround was to unparent the scrolling list from the draggable window, and use a follow script to update the position of the scolling list when the window position changed. Not a huge deal, but not intuitive, either.

Anyway, I love NGUI! I'm a huge fan.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: breakmachine on November 15, 2013, 12:04:15 AM
How about packing dynamic fonts in separated channels (rgb). Would that optimize anything?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Nicki on November 15, 2013, 04:01:12 AM
The single most annoying thing in NGUI for me, is a tiny thing with how buttons-touches are handled.

If I tap down on a button then slide my finger off the button outside, then button should "deselect" (visually change away from the tapped state) but no other buttons should receive input if I slide over them, since the one I tapped down on should be the only input receiver. If I think slide back over the original button it should re-activate, and if I release on top of the same button I release on, it should count as a click.

The way it works now is weird to me.

Either you have sticky press, in which the button keeps being tapped down no matter where your finger slide, or sticky keys of, in which it's even weirder and you can slide over a new button and have that count the same as a OnPress.

I want to be able to slide out of a button to cancel the click visually, but be able to slide back to re-enable it.

Ramble ramble.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: BGL on November 15, 2013, 04:26:03 AM
Data binding has already been prototyped, and the Pro version has some testing code in it that has the framework for it. I'm still not entirely sure I understand what's the best use case for it. I use it to be able to set both properties and values of a remote script by name -- which, while cool, seems like a strange way of going about it, since I can just do a GetComponent and set the value directly. I can think of a couple semi-useful use cases, but I'd like to hear what you guys would use it for?
Data binding is very useful to totally separate UI logic and UI appearance. Your UI code will not relay at all on the hierarchy of UIWidgets, they are separated. For example with data binding if you expose a bool like MyLogicIsValid, you can change totally your UI without a line of code, for example changing the appearance of a button to look disabled/enabled, display a string that tell the user that something is not valid and even play an animation on value switch. Another example, if in my UI logic there is a list of 100 items exposed, I can choose to show them 10 by 10 in a scroll panel, then I can add a preview for the selected one without changing any code; I can even change what I show for each item, as far the properties are exposed, and how, if for example there is a string property, I can show a UILabel or a UISprite.
When you work in a team it will help you dramatically improve UI development speed, maintainability, big task splitting...even more in a big company.
I can continue with the benefits and the use cases, but I think this could be enough.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 15, 2013, 07:14:47 AM
@haueryou26: It's not possible to pack RGBA textures, which are 4 channels, into a single channel. Packed fonts can do that because they only have 1 channel of data (RGB is assumed to be pure white, only alpha is needed). Unless your entire UI is made up of semi-transparent white areas, it's not possible to pack it into R, G, B, and A channel.

@BGL: What would you bind to what in your example? Say the "enabled" state of a collider... bound to what? Any script and/or animation can change the enabled state easily. Same would be with any widget property. The benefit of doing this is what escapes me. An artist-centric use-case example would be nice.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Antares88 on November 15, 2013, 08:59:47 AM
Aren,
it's really great that you take into account the voice of the community for the future of NGUI and uGUI.

That said, IMHO it would be useful to many if you manage to spend some time on the documentation and tutorials.

There's still a mess around with info related to old NGUI versions. Having more complete and up-to-date material in evidence would be great.

Thanks for your efforts.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: haueryou26 on November 15, 2013, 10:51:18 AM
@ArenMook:  So I thought there might be some push back on the idea of packing UI into the R,G,B channels.  So I'm providing a link of another person proof of concept that you can pack into the individual channels of a single texture and still have it work for yours needs. Please look at http://www.polycount.com/forum/showthread.php?t=89682&page=9  This entire environment was created in this method of having a single texture.  One might say well that is an environment and that's why you can get away with it.  I personally don't believe that to be the case.  I believe you can use this same process for UI and each channel would by default be black and white.  You would get your variation from unique shaders or hard coding in albedo tints.  Its true that if you have UI that has multiple colors associated with a single image you would not be able to do this.  In my pipeline if this happened where I had UI element that needed a range of color in a single asset I would simply make a atlas for these fully colored UI elements and another atlas for all my black and white assets.   I have already worked with studios doing this kind of optimizations at Microsoft and believe this is where the industry is going.  Anyways if your don't have plans to support this memory efficient UI workflow, I understand. I do however see this being a huge win for your product and would have bought your product again just to have this kind of functionality.

Ps.  I apologize for the run-on sentences, I'm super tired this morning.
-Stephen Hauer
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 15, 2013, 11:28:08 AM
Yes, if you create a single texture where you encode black-and-white sprites, it works fine. As I said, it only works if they are black and white. The only way to get color in there is to use one of the sprites as a mask as well. So now you have a black and white detail texture + color mask.

It's not something suitable for GUI atlasing. You can create an atlas like that in Photoshop by hand, surely, but it is not something that would work in a production environment with RGBA user textures.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Quarkism on November 15, 2013, 02:36:37 PM
Regarding DataBinding :

http://www.avariceonline.com/Products/Mvvm

I plan to be releasing this shortly for under between $20 and $50 (not sure yet). I'm currently revising the Lobby for NGUI 3.

If the new UI is still not released then I might just release it with NGUI with a promise to upgrade.

One caveat, it does use reflection and JsonFX. It should work on IOS (I don't use Reflection.Emit) but I haven't tested it yet as I do not have a mac.

I come from a microsoft background where MVVM is a big thing. The solution is molded after that. It supports using both monobehaviours and model classes (clr objects) as binding targets, complex hierarchies, two way binding and a bunch of other features.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 15, 2013, 10:00:29 PM
Hehe... a plugin for uGUI -- a system that's still in pre-alpha? :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Ugur on November 16, 2013, 12:46:04 PM
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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Photic on November 16, 2013, 04:24:12 PM
I've been working on a game that only uses ngui. My game might not be what ngui is designed for but it works a lot better than the current Unity GUI system.

I really like the boxcollider resize option on a widget that has a boxcollider, but I would also like to be able to resize a collider based on the size of a different widget.
For example:
 Button (has box collider)
  Background (with UIStretch)
  Label

I would like the boxcollider of the button to be the same size as the stretched background. I have made a script to handle this case, but I think it would a nice supported feature.

I'm not sure if it's been removed, but I can't seem to find the option to have a max width on labels anymore. In certain instances I would like the text to wrap rather than resize.
Previously when the option was there I would calculate the size of the entered text then calculate the how wide I wanted the text to be then set the width to that value. Then I would calculate the number of lines used based on total text entered and resize the background of the label to the desired height. All of this was pretty complicated.

So it would be extra helpful if there was an option to resize/stretch a widget based on the size of the text and to constrain the text width.

My next issue might just be my lack of understanding. I created a scroll view using the dual camera style and when I use grid or table it seems to center the list of items on the upper left bounds of the first item until I scroll for the first time, they're still off but they're closer to center after scrolling, but strangely the camera happens to jump to their center, instead of the items being centered in the camera view.

I would also like it if the grid and table supported different/dynamically sized items, I could be wrong but they seem expect all of the items to be the same size. I ended up creating a script to calculate and position items according to the axis they're stacked on to handle this. Though It would be nice to see a supported feature that would have items appended based on the total height/width of the item instead of a predefined size.

Thanks for listening :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 16, 2013, 08:47:04 PM
@Ugur: Thanks, that's pretty detailed, but I have this feeling that you're not using the 3.X cycle version since you mention about having depth issues, and 3.X is all depth-only based and dynamic labels work the same as any other widget with depth.

@Photic: Regarding your box collider on button... why don't you just add a UIWidget script to your button then toggle the adjust collider option? I guess it's a fairly hidden feature...

Max width is just width of the label now. Resizing widget based on the size of the text... ResizeFreely on the label. If you want another widget to resize to envelop that label, UIStretch on it using that label as the container should do the trick.

Most of what I gather from this thread is this: NGUI is a powerful tool, but I suck at creating non-programmer documentation. :) I really should work on that. I'm thinking of adding help buttons to components and linking them to posts here, where users can always ask questions related to the topic directly.

What do you guys think?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Photic on November 16, 2013, 09:20:43 PM
Oh awesome! Thanks for the info, I'll give that a shot.

Though I do feel dumb now because I am a programmer :P hehe
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Ugur on November 16, 2013, 09:27:54 PM
@Aren:
No, i'm using NGUI 3.0.5 and i still get depth sorting issues with that in complex uis where things sometimes get sorted in front and sometimes behind other objects etc and i have to always check what's the issue with which panel etc.

Most of what I gather from this thread is this: NGUI is a powerful tool, but I suck at creating non-programmer documentation. :)

I'll just assume you don't mean it in nasty way, and yeah, adding links to documentation one can easily access is not a bad idea in general. But yeah, the issues i listed are not due to lack of documentation at all.
Nor am i a non-programmer =)
I listed the strengths NGUI had and still has on a few ends over OnGUI and various other gui solutions for unity which came before NGUI. Thing is, it needs to evolve considerably (and so would unity's new GUI system have to if it follows NGUI's setup too closely) because its just lacking on a few ends which lead to controls not being well reusable accross projects and one spending way too much time on creating basic controls like a button, checkbox, dropdown menu, list menu or a scrollpane for every project with a bit more complex UI.

The basis is there and usable, but that there are no builtin out of the box ready to use controls like buttons, checkboxes, dropdown menus, list menus,scrollpanes etc means one has to build all those controls together before one can actually start to design/lay out the UI.
Why are there no prefabs for those controls using a builtin atlas?

And yeah, it would also need a gui skinning system with the then builtin standard controls coming with their default skin and then one could just replace those sprites in the atlas with own ones and have those controls ready to use.

Lack of such a system means one has to recreate way too much from the ground up for every project since one basically can't reuse controls one made using one atlas in another project using another atlas easily.

I don't think such and other things i listed are helped with better documentation, but yeah, if they would be implemented that would mean people spend way less time on creating basic controls, have em ready to use and also ready to use in multiple projects with different atlases etc and yeah, that would help to reduce the for you beginner seeming questions since the beginner stuff would come in ready to use form out of the box =)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 16, 2013, 09:41:11 PM
Quote
Why are there no prefabs for those controls using a builtin atlas?
There are prefabs for all basic GUI elements uGUI using a default (built-in) atlas. Come to think of it... I don't know why I never added them to NGUI. I really should.

As for my non-programmer documentation comment... majority of the documentation I write is in the code, so a dev would need to navigate to the function in the code to get a description of what it does (or check www.tasharen.com/ngui/docs/ I suppose). I was just thinking that adding a way to automatically open the web browser to get an overview of the component would be handy. Ima do it.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Ugur on November 16, 2013, 09:56:32 PM
Ok =)

Regarding the builtin controls: yeah, would be good you add them, but its not just that. NGUI also needs a system like the GUISkins in OnGUI. Where it defines the settings, textures/sprites/sounds etc for all the standard elements of the standard controls once, the builtin controls come with that and when one adds a builtin control to a project it adds the textures used in that skin for that control to your atlas. If you already have sprites with those names in your atlas it just uses those so that you can reuse controls between projects more easily.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: charmandermon on November 16, 2013, 11:13:19 PM
I would greatly like multi monitor support. Right now the anchor system really only works for one monitor.  It would also be great to have moveable "dockable" GUI zones for customizing your in-game GUI interface.

Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: vexe on November 18, 2013, 04:14:12 AM
I read this thread when it had 0 replies - But didn't have to write my opinion.

1- @Aren: you said it in Unite 13 "Atlases suck!" - And they do suck, hard! - They break a lot! - And, what if you wanted to change your atlas for your UI? - You'd have to go to each widget that used the previous atlas and change to the new atlas instead, ahhhh.........
I really wish to see atlases removed - And provide us a better/easier way to manage sprites with good performance and number of draw calls.

2- Better clipping - and an effective and easy way to create a modular clipping panel (http://www.tasharen.com/forum/index.php?topic=6572.msg31021#msg31021)

3- Advanced UIInput (I would really love to see this) - Supports putting the mouse caret where user clicks and highlighting text. (http://www.tasharen.com/forum/index.php?topic=5725.msg27141#msg27141)

4- Letting the UI event type, detect colliders on disabled widgets? That would be nice me thinks.

5- An easier way to create modular UIs?

6- An easier, less pain in the butt workflow in general :D

7- Less painful migration operation in major upgrades - (Unlike 2.x to 3.x - where I had thousands of code depending on the old system - I had to recreate the UI from almost scratch to keep up with the new stuff, please make it less painful next time...)

8- More "advanced stuff" (mainly coding-related) NGUI tutorial videos?

9- Lastly, the thing that really sucks about NGUI from the beginning: THE DOCUMENTATION! - It's always been known that NGUI documentation is the worst thing in it, it's a lot more developer-oriented than user-oriented - Very little info on it, barely the name of the methods and their parameters... ahhh come on! - Please make it better, add more details, examples, etc. I really think that if the docs where better, you would have a lot less pressure on you in the Forums.

Thanks! :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Isamson on November 18, 2013, 10:53:06 AM
What I'd like to see is a style associated with fonts, something inspired of the styles in word. You could create some styles (title1, title2, tooltip, etc.) that could be changed and mass-updated.

This would really same me time when my producer decides that this font needs to be changed or that the color for these titles are off a little.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jingato on November 18, 2013, 11:49:45 AM
The biggest thing I would like is the ability to have parameters in the events for buttons. I wrote my own behavior to it, but it would be nice to have it built in to the UIButton with the new event system.

I've attached my version if anybody wants to try it out.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Ferazel on November 18, 2013, 01:29:59 PM
I'm really looking forward to transitioning to uGUI. The only concern is that we've been really spoiled by your ability to push out fixes and new versions quickly and efficiently. So my request is to see if we can make sure that we can maintain some sort of ability to download updates without waiting for new Unity versions.

In regards to GUI functionality and some holes that I see in the functionality.

Text Flow: The biggest request by far, but I'd really love to get some text flow improvements. This would include functionality such as having text flow along a a curve or other shape. This would allow you to make a label fill a non-rectangular shape such as around a circular UI element. I'm not sure how you'd do this other than maybe making a new subset of components (similar to tweens) that would alter the flow of text along an animation curve or something. Another part of this feature would be to allow text to have flow elements that it would watch out for and would create new line breaks based on the collision with these elements. For example, if I have a sprite in the upper left of a text area, the label would automatically position itself in the UILabel where it would not overlap with this sprite. Having this done dynamically would greatly help with localization.

Dynamic Font Emoticons:  This is pretty self-explanatory, but having an easy way to embed sprites in a UILabel would be great. Having some advanced parameters could also be great. Such as [#spriteName#DEPTH:-1#SIZE:32x32] to get a sprite rendered below the label's depth at a size of 32x32. The reason to specify the depth is to try to get this sprite to batch with the other sprite elements could be +/-. The reason to specify the size is that if I want to downsize a larger icon to fit into the label, I may need to shrink it to fit it into the space. Or the sprite that I'm using may not be square. Then being able to link to an atlas on the label that the text would automatically space appropriately to fit.

Multi-Edit UITexture: This is a relatively small request, but since you added it for some of your bigger ones (UISprite and UILabel), I thought I'd request this one as well.

Android Mouse Support: Another minor request, but having supported Android mouse support implemented into the tool would be nice so that I don't have to worry about it being overwritten by updates.

Non-Rect Sprite/Texture Mesh: I'd like to be able to specify a mesh for sprites if desired. So that I can provide a mesh that is non-rectangular in order to cut down fill-rate if there are large portions that are alpha. If it came with a snazzy editor that'd be sweet too, but at the very least a link to a custom mesh if desired.

Obviously, these kind of features are pretty advanced. I really appreciate you asking the community for some feedback. I hope that after uGUI you might work on integrating TNET into Unity. Although I have a feeling that keeping up with community requests and bugs is going to be a full-time job. :D
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on November 18, 2013, 01:39:49 PM
So my request is to see if we can make sure that we can maintain some sort of ability to download updates without waiting for new Unity versions.

I'm also interested in this part. What do you have to say Aren/Unity?  ;D
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: indiefreaks on November 18, 2013, 05:51:34 PM
Hi Aren,

I read all the threads and I really appreciate most of the feature and improvement requests posted by other devs here.

Something that I'd love to see as part of NGUI is a dedicated tool where my UI hierarchy would have its own Unity Editor Window that wouldn't mix up with my game scene.
I'd like to be able to tweak my UI without having to navigate through the entire UIRoot, UICameras, Panels and so forth...
A simple NGUI Hierarchy Window with all my UI stuff there that I can click and operate directly.

As a nice to have and I can hardly see that being made for this major release, I would also love to see a design decision made on the way that you recommend using NGUI: Weither it's a simple Model-View, a MVC or MVVM recommended structure, I believe this could help developers understanding how they can get the most of NGUI.

Just my 2 cents as I'm already sold on NGUI for my current needs ;)

Thanks
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: OnlineCop on November 19, 2013, 01:46:49 AM
I would really like deprecation documentation (either inline, or links to external sites that could detail it). For example, in 2.7 and earlier, UITweener's 'onFinished' was a delegate. In 3.0, it is a List<Delegate>. So code that used to work with
  1. TweenPosition.Begin(gameObject, 1f, Vector3.zero).onFinished += MyOnFinishedHandler;
no longer works, and there is no documentation that appears to explain where it went, or what it should be changed to (yes, instructions are found in these forums if you know where to dig... having a nice link to them would be very helpful, though).
  1. // Deprecated functionality, see:
  2. //   http://www.tasharen.com/forum/index.php?topic=[something]
  3. // for instructions on new implementation
or
  1. // Functionality changed from 2.7.x to 3.x. To use this, you must ...

EDIT 1:
I didn't see that there were 3 pages of comments before I wrote that up, and it looks like my concerns were already shared and discussed:
Quote
I'm thinking of adding help buttons to components and linking them to posts here, where users can always ask questions related to the topic directly.
Oh well.

But, I would be happy to contribute time to expanding documentation, writing up simple tutorials for various components, etc. if that is a big task. I've always found things like user-committed tutorials to be the best part about forums, so don't mind contributing myself.

EDIT 2:
This is just a nitpick, but I notice that several files don't have any Copyright info, some do and go only from 2011-2012 and others from 2011-2013, many have different line endings (some LF, others CRLF), and encodings vary (ASCII, UTF-8, UTF-8 with BOM, ISO-8859, etc.).  :-X
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: vexe on November 19, 2013, 01:48:41 AM
One more thing I'd like to add - Is to make NGUI code follow the O in SOLID - Open for extension and closed for modification. Sometimes I need to create a custom type of UIInput, some of the stuff is private - why not make them protected? - I have to come in and edit your code - 'open it to modify it' - to be able to extend it.

Just a thing to keep in mind.

Thanks.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: nah0y on November 19, 2013, 05:08:08 AM
Hey !

ScrollingList and ResetPosition
I know in our last game I had a AHAHAAAAAHH issue with this. I have a list of objects in a draggable panel, and at some point, if the user leave the screen and come back, I want to set the list on the first element again (in case he has scrolled the list). I had to use a mix of myUITable.Reposition(), myUITable.repositionNow = true and myDraggablePanel.ResetPosition to make it work. It's so f***d up that I can't even explain it lol.
What I know is that, just calling ResetPosition was offseting my list 30-40px every time I called the method...

Anchor + size
It would be great to have a way to create a group of widgets, anchor everything at the top of the screen for example AND at the same time give it a size. So we could have a group that is on top, and take 25% of the top screen.
Then we could add another group, that we anchor at the bottom of the first group, give it a 25% height also etc...

Great way to see multiple resolutions
Maybe have a window where you can see how your current UI looks like in multiple resolution. The Android team did a wonderful tool to do that, you can check this here : http://tools.android.com/recent/multiconfigurationediting and a video here (better) : http://www.youtube.com/watch?v=_Hf5P2hjv5k
PS : Bonus to also see what your UI looks like in multiple languages directly in the window :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on November 19, 2013, 11:05:13 AM
One more thing I'd like to add - Is to make NGUI code follow the O in SOLID - Open for extension and closed for modification. Sometimes I need to create a custom type of UIInput, some of the stuff is private - why not make them protected? - I have to come in and edit your code - 'open it to modify it' - to be able to extend it.

Just a thing to keep in mind.

Thanks.

Same problem here.

I have extended several components and copy paste all NGUI code because it's not "protected" and "virtual".
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 19, 2013, 06:42:18 PM
If you guys want me to make certain things public / protected, just ask.  Another user has done exactly that yesterday, and the functionality he has requested can be already found exposed in 3.0.6.

Clipping repositioning has been fixed in 3.0.6, and the way you specify clipped areas has been amended (you can drag handles as if it was a widget).

Anchoring / stretch system is scheduled for a re-design in 3.0.7. Although as a note of warning I've attempted to do it 3 times in the past, and each time it was like pulling on a string from a ball of yarn. One change leads to another, that one leads to two more, those lead to four more each, and so on. If I was to re-design NGUI from scratch, this would be trivial -- but keeping things backwards compatible... that's hard. And it's a pain in the ass. o_o

Emoticons for dynamic fonts is indeed something I've been meaning to do, but somehow it always seems to take the back shelf...

As for updates to uGUI... well, uGUI will come with its source code being available and public for you to modify, so it would be possible to have quick fixes. Source code files grabbed from that repository will simply replace built-in functionality -- just like if you were replacing a built-in shader with your own custom one. That said, it's highly unlikely that I will be doing these fixes. I've been itching to work on game dev again, so that's what I am going to do next month onwards. Fact: NGUI was the result of me working on a game. So was TNet.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: mikejkelley on November 19, 2013, 07:57:33 PM
Playmaker Action Packs.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Skjalg on November 20, 2013, 05:32:49 AM
Just like with the 3.0 update, I don't really care if its not backwards compatible as long as you specify that it isn't.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on November 20, 2013, 03:22:12 PM
- I want to see a "circle" type clipping on UIPanel. We have one done by ourself but everytime you update NGUI we have to edit two or three scripts adding that...

- Same with UIGrid pivot option. We have done it by ourself and in this case it's worse because we had to copy all your code and replace it overriding Reposition method with "new" word. Also, it would be nice to be able to extend it and animate each child position with iTween/HOTween/etc...

- UIGrid Reposition() 100% reliable. I have seen sometimes that I have to do a Coroutine and WaitForEndOfFrame because if not, It doesn't give correct child transforms.

- UIGrid sort order Ascending/Descending. It's really easy to implement.

- I would like to see a generic script that handles all NGUI events with the new inspector (see UISlider OnValueChange, for example). This could replace UIButtonMessage.

- A better Tween control. I don't like relying on the component state. I would like to control them with Play, Pause, Stop and so on... methods.

If you guys want me to make certain things public / protected, just ask.  Another user has done exactly that yesterday, and the functionality he has requested can be already found exposed in 3.0.6.

We could but I think that it's better if you take NGUI scripts one by one (every day 4 or 5, when you have time) and change to "protected virtual" all methods that you think that it's worth of extending.

I said that because If we are saying "method X from script X" and later another, you are going to expose one in 3.0.7 another in 3.0.8 and so on...

Anchoring / stretch system is scheduled for a re-design in 3.0.7.

Can you explain this or give a screenshot/example? I'm really curious  ;D
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 20, 2013, 03:33:06 PM
I will once I implement it :P
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: DarkMagicCK on November 20, 2013, 11:40:13 PM
For me, I would send a feature request for a image-ratio-button. Think about tabcontrol's tab button. In game, we often need a panel which has its tab control switch between different panels. The button in the tab control has five states instead of ImageButton's four, additional a selected state. The selected button will be stay on Selected State, while the ImageButton cannot do things like this.

And one more sliced sprite render option - allow the middle part not only stretch, but also tiled. This can be done by combine sliced sprite for head&tail and a tiled sprite for the middle, but I think it's more convenient to use just one sprite instead.

And about panel alpha - we usually need a function for a whole panel's fade in/out, but the nested child panel will not be affected by its parent UIPanel's alpha. I think child UIPanel's render alpha should be inherited from it's ancestor until the root. (eg. panel with alpha 1, a father panel(alpha 0.5), a grandfather panel(alpha 0.5) should result be rendered with alpha 0.5*0.5*1 = 0.25).
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 21, 2013, 04:08:46 AM
Panel alpha not being nested... whoa now. I could have sworn I've done that ~10 months ago... I guess it was uGUI that I did this in instead. I'll patch it in.

Edit: The latest 3.0.6 now has properly cumulative alpha.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Wahooney on November 21, 2013, 05:29:46 AM
I'd love to see:


More most likely to follow ;D
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: KeithT on November 21, 2013, 07:43:21 AM
Still on 2.x, so 3 might already have improved some of these:

1. Depth positioning Ahhhhhh
2. Some sort of master/template/skin mechanism so you can create, modify and consistently maintain things of a type e.g. all 35 buttons are the same design
3. The way different inputs in UICamera are handled. The inability to differentiate between mouse and keyboard input is a nightmare, we have had to do some horrible hacks to make popup lists work with just the keyboard, just the mouse and a combination of mouse and keyboard, which is the real situation for the billions of PCs out there.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: gyd on November 21, 2013, 09:37:39 AM
1. Camera Limit in Rect:
   in order to design some UI for ipad*/iphone5, base on iphone4 resolution, we need to limit the viewRect, and ensure the anchor follow the rule.
   for example, the UI design for iphone4 shows with black blocks at left/right on iphone5 , and black blocks at top/bottom on ipad*, every anchor work fine to match new limit( match screen as default), and every UI out of limit will be cutoff, to make sure Widgets are hided after tween or moved

2. Tooltip in TouchDevices
   of course we can do it on our own, but it will be perfect if tooltips shows when matching some conditions, ex: pressed 1 seconds without moving( or admit a bit movement )
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: indiefreaks on November 21, 2013, 12:43:47 PM
Sprite base collider/trigger : Sometimes, you want to be creative with your UI and you want to create some funky buttons. I'd love to be able to create an optimized polygon shape based on the background sprite to test for the great NGUI event system.
Oh... and it could be generated on the fly :p

Most useful for dynamic radial menus for instance instead of making a custom raycast on the whole menu, you could just have a single pie section generated depending on the number of items presented in the menu.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: breakmachine on November 22, 2013, 02:51:14 AM
It would be nice to be able to "embed" a dynamic font in an atlas plus making the font pack to rgb. This would make depth managing a bit easier (sorting widgets manually by atlas to reduce drawcalls can be tedious).

Whick makes me think that a function for setting an order for atlases and one for sorting widgets within a panel according to that would be nice too :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Nicki on November 22, 2013, 06:18:32 AM
One thing that I seem to often stumble into:

There's no easy way to flip a sprite (both horizontally or vertically). This can become annoying if you have a single texture for a corner piece that's identical in all corners, because you either have to mess around with setting scale to -1 on a parent or rotating each piece.

Rotating is not the same as mirroring, so that doesn't always solve that problem. Would be nice with two simple:

[ ] flip vertically
[ ] flip horizontally

on each widget.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on November 22, 2013, 12:04:53 PM
One thing that I seem to often stumble into:

There's no easy way to flip a sprite (both horizontally or vertically). This can become annoying if you have a single texture for a corner piece that's identical in all corners, because you either have to mess around with setting scale to -1 on a parent or rotating each piece.

Rotating is not the same as mirroring, so that doesn't always solve that problem. Would be nice with two simple:

[ ] flip vertically
[ ] flip horizontally

on each widget.

+1

I use "-1" scale on X o Y Axis because there is no other way.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Erhune on November 23, 2013, 11:30:57 AM
I don't have anything new to add, but I just want to add my voice to some previously made suggestions:

Better layout support.

Ex: I want to have a bunch of widgets lined horizontally, each of them with variable width (think UILabel for example), and some spacing between them. I want to center the whole bunch relative to another widget. Bad ASCII drawing:

            [Reference Widget]
[Variable 1]  [Variable 2]  [Variable 3]

There might be a solution with anchors, but when you start to have a variable number of variable-sized widgets, it starts to crumble, so I always find easier to write an ad-hoc script (thank you so much for UIWidget.width in 3.x, by the way, it made my life so much easier!)

Selection support in UIInput.

I use a OnGUI Input() for the chat in my game, because it has proper support of selection, copy&paste, all well integrated with the OS default controls. I would kill to replace those by a proper UIInput, for so many reasons (simplicity, positionning, performance, able to render to texture...)!

Styled text in UILabel.

Basically the subset of pseudo-HTML usable in GUITexts: in addition to colors (which we have now), mixing font styles (italic, bold), sizes... Even better would be: line spacing (I saw you're doing something about this in 3.0.6, but I guess it's one setting for the whole text, not per line/paragraph...), multiple fonts in one label, clickable "links" that send events, or maybe even embedding arbitrary widgets in the text flow...

--

That's all I have for my list to Santa Claus for this year :p Anyway thank you again for your work and listening to the community, and keep up on the excellent work! (the pace of improvements in 3.x is fantastic!)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 23, 2013, 11:49:00 AM
Better layouting (is that even a word?) support and snapping for widget positioning is the main feature for 3.0.7.

3.0.6 has been the biggest update yet, feature-wise. The downside of making improvements is now I have to make some new videos to go with them!

As others have pointed out many times... NGUI is an uber powerful tool -- but learning it can be a challenge. So my main focus with NGUI 3 updates is to make it as easy to use as possible and to remove as much "wtf?" from it as I can.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Erhune on November 23, 2013, 11:50:10 PM
Better layouting (is that even a word?) support and snapping for widget positioning is the main feature for 3.0.7.

Fantastic !

3.0.6 has been the biggest update yet, feature-wise. The downside of making improvements is now I have to make some new videos to go with them!

As others have pointed out many times... NGUI is an uber powerful tool -- but learning it can be a challenge. So my main focus with NGUI 3 updates is to make it as easy to use as possible and to remove as much "wtf?" from it as I can.

Yeah, I admit that even after using NGUI for more than 1 year, I learned a few things I always overlooked from the new docs you posted recently. I think using the forum "wiki-like" with a topic for each feature/widget is a great idea!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: sakurawarskula on November 24, 2013, 10:43:28 AM
NO MORE FANCY FEATURES,FIXED KNOWN BUGS PLS.
Otherwise,we got no steady version to use after each upgrade.
                      --------- a paid NGUI user
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Devil_Inside on November 24, 2013, 11:46:04 AM
I try to make my UI "pretty", so I try to add tweens and fades wherever possible.
I'd really like to see some improvements in widget alpha nesting.
If I want to fade out a button, I'd have to tween both label and background sprite manually in the button script. What if the label is 50% transparent by default, I'd have to keep this default alpha value somewhere and use it in in the final button alpha calculation.. What if button's alpha is set to 0.25 to hide it, but another script changes the labels alpha to 1?

I know you've added panel alpha nesting, and that's a great feature! But I can't add every nested widget in it's separate panel, so some improvements in this domain would be really welcome!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: charmandermon on November 24, 2013, 02:47:54 PM
I just wanted to say that I absolutely love the new drag and drop prefab support. I was able to make gui in like a fraction of the time.  Very well done!

I would also like to suggest a custom ngui window with all of the current available controls/widgets rather than hunting the project view for them.  I would imagine it to be more like a visual gui builder then, like visual studio and Xcode. 

Lastly Keep those new widgets coming that is freaking awesome how it is.



Thanks greatly!
Dustin
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 24, 2013, 04:49:03 PM
Get out of my head, charmandermon! :)

I am going to be adding just that. The idea is to have a "prefab" window where you can place your commonly used controls so you can easily add them while making UIs.

P.S. I also snuck in the widget snapping feature in the rc3. I wonder if anyone noticed.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Devil_Inside on November 24, 2013, 05:18:45 PM
The sprite gizmo sometimes interferes with default unity movement tools so I start rotating or scaling the sprite instead of moving it. I also never use the gizmo to scale or rotate, I do it within the inspector. Can you please add a way to disable the gizmo without folding the sprite component?
Edit: I feel stupid now. Just found how to turn off the handles from the NGUI menu.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: nerophon on November 25, 2013, 11:15:56 AM
Hi ArenMook,

Sometimes the best way to figure out what could use improvement is to have an ui/ux designer tell you what they want... and suddenly you have to implement it somehow. That's happening to me right now, so I'll share some general details of what was required, plus my conclusions about what seemed to be needed.

Firstly, we're doing mobile, so we need something that looks good on many different screen sizes and resolutions. Of course, the first issue was pixel density. As mentioned by others, the proper way to do ui for mobiles is to have a layout that is pixel-perfect at Density Independent Pixel scale, then changes based on density rather than height. This keeps things like nav bars the same size, no matter what device you're on.

After that, I found figuring out how to use anchor / stretch to layout elements in the desired way was a bit clunky. I am happy to hear you are going to try something new. In respect of this, one task I had was to create a bar that stretched across the screen, containing three buttons laid out in a grid. I naturally thought of UIGrid, but the spec was for a fixed pixel space between the three buttons, with the buttons stretching equally to fill the space. UIGrid cannot do this as of now, so I had to do it manually. Therefore, perhaps a grid upgrade is in order? And what about those super awesome grids you find on the net these days that have various sizes of squares, e.g. www.ted.com? That would be cool.

Next is a gripe: I implemented a scroll view, without softClip, prior to 3.0.6. It worked fine after I looked at the examples for a bit. However, now suddenly in 3.0.6 it broke because there's an automatic change to softClip in Awake. So I went back in and commented it out. But why force softclip on scroll views? Our scroll-view just goes off the sides of the screen.

Also, because of the layout system, I had to write my own UIAnchor subclass called UIAxisAnchor for our scroll view, which anchors in a single axis only. This required changing some of your private methods and fields to protected, which has been mentioned by others. But also, it suggests that the stretch / anchor system is, as stated above, not really sufficient for all use cases.

Speaking of that, the spec for our scroll view was that the elements needed to be a specific number of pixels less wide than the screen width. Again, I couldn't find a way to do this directly with NGUI, so wrote a script that does it in update. Obviously, not super-efficient. Perhaps I will have it do it once on launch, or do a screen-size change event or something. Perhaps NGUI could provide this? Or maybe it already does... who knows?

A final thing I've been asked to do is rounded corners. Easy enough you say! But wait! How about rounded corners on dynamic images downloaded at runtime? Ahaha! Harder. So perhaps, as mentioned by others, some kind of ability to use non-quad meshes, or some other solution to the problem of "masking with alpha".

Okay, that's all for now. As I continue implementing things, perhaps I will encounter more ideas for improvements. If so, will post.

Many thanks,

Nicholas Bellerophon

EDIT: turns out the spec for the scroll-view actually asks it be an infinite loop, including auto-scrolling on a fixed period, with breadcrumbs indicating current location. Looks like I'll be doing a fair bit of work here to turn a standard NGUI scroll view into this "carousel" thing. Hope this is useful.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Jaimi on November 25, 2013, 02:35:28 PM
Support for "Skinnable UI". This is complex, but I think it could be done several ways: Sub-atlases that define UI elements. Named lookups of items. Import of Unity GUI skins. Etc. 

Basically, I'd still like to have all what ngui has right now, but with the option of simple prefabs that use a sub atlas or naming convention, so the textures can be swapped out to change the look. Example - changing the fantasy skin to a sci-fi skin.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Yukichu on November 25, 2013, 06:23:03 PM
Granted, I haven't read the rest of this much, but...

I would like:

1.  More 'readable' code.  Much too often there are if/else statements with the executing code on the same line as the if/else.  Yes, it saves space but trying to read through the code to change something for customization becomes more mind-numbing than it should be.

2.  As stated earlier, more virtual methods so we can create extended classes without worrying about them breaking every time we upgrade.

3.  The 'lego structure' is fine, but I can see how you want to appeal to the masses in order to sell more product.  Do whatever you need to sell more product, which will ultimately result in better development.

4.  I haven't tried the new scrollable UI thing, but initially setting up the old one was... a complete and utter stupid headache, particularly in that the tutorials at the time neglected to state you needed a collider and some other steps.  I've vaguely looked at the new documentation and I hope it is better, as this would be one my wishes - better, up-to-date documentation.

5.  While I do not actually have a need for this (yet) being able to manually order the draw calls of objects could be interesting.  You'd just say, in whatever manner, 'draw this after the normal order of draw calls' so you could explicitly state what goes on top.  I know there are layers and their purpose works wonderfully; however, when items are within the same layer the draw calls are managed by the innards of the panels.  It seems it currently works on a 'last created, last drawn' system, which works great... but what if I wanted to always keep something drawn on top while in the same layer as others...  Yes, I understand it would result in more draw calls, but it would result in more flexibility.

6.  Other than that, just keep on truckin'.  I love NGUI.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: charmandermon on November 26, 2013, 02:13:39 AM
I would like to request a multiple tab group window prebuilt widget in our new group of widget prefabs :)

Thanks
Dustin
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Nicki on November 26, 2013, 09:44:04 AM
Nerophon: Masking with clipping can be doe by changing the shader used for the UITexture. See http://nickithansen.dk/masking-and-clipping-textures-using-shaders-in-ngui/
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jeldrez on November 26, 2013, 01:20:47 PM
A lot of us are asking for UIGrid/UITable alignment options (left/center/right)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: fpuig on November 26, 2013, 06:57:51 PM
alpha nesting between widgets
I try to make my UI "pretty", so I try to add tweens and fades wherever possible.
I'd really like to see some improvements in widget alpha nesting.
If I want to fade out a button, I'd have to tween both label and background sprite manually in the button script. What if the label is 50% transparent by default, I'd have to keep this default alpha value somewhere and use it in in the final button alpha calculation.. What if button's alpha is set to 0.25 to hide it, but another script changes the labels alpha to 1?

I know you've added panel alpha nesting, and that's a great feature! But I can't add every nested widget in it's separate panel, so some improvements in this domain would be really welcome!

+1 to adding support for alpha nesting between widgets

On our UI we need to fade in/out buttons and parts of the screen. But making each of those buttons a separated panel add a couple of extra drawcalls which we would like to avoid as much as possible.

The ideal for us will be to be able of adding an empty widget on the root of the button in order to control the alpha of all the child widgets. Pretty much like how it works with the nested panels but without adding drawcalls.


UITweener options to initialize with the 'From' value

There are lot of places where we are using Tweeners for our UI animations. For instance, when enabling our main menu, we quickly move its buttons from outside of the screen into the right location but with different delays.

Those tweens are set by the artist on the editor and they are executed as soon as the screen is enabled. But given that they have a delay then they start in the position the widget is in the editor (inside the view area) and only after the delay time passes they get moved into the "from" location.

We modified the UITweener and UITweenerEditor to allow forcing the tweener to place the value into the "from" position as soon as its enabled.

UITweener:
  1.         public bool InitializeWithFrom = false;
  2.  
  3.         void OnEnable()
  4.         {
  5.                 if (enabled && InitializeWithFrom)
  6.                         OnUpdate(0, false);
  7.         }
  8.  
   
UITweenerEditor:
  1.         protected void DrawCommonProperties ()
  2.         {
  3.                 ...
  4.  
  5.                 if (NGUIEditorTools.DrawHeader("Tweener"))
  6.                 {
  7.                         ...
  8.  
  9.                         bool InitWithFrom = EditorGUILayout.Toggle("Init With From", tw.InitializeWithFrom);
  10.                         if (GUI.changed)
  11.                         {
  12.                                 ...
  13.                                 tw.InitializeWithFrom = InitWithFrom;
  14.                                 ...
  15.                         }
  16.                         ...
  17.                 }
  18.                 ....
  19.         }
  20.  

Maybe that or a similar approach could be implemented into the Tweeners so that the artist could schedule the animations without having to move the objects into the animation's initial values.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Rahaio on November 27, 2013, 05:48:13 AM
There are two suggestions I would like to make for improving NGUI:
• It would be great if you could add multiple objects as containers in the UIStretch, so you could tell a sprite to be as wide/high as sprite A plus sprite B plus sprite C. That would be very helpful for creating responsive interfaces.
• I would appreciate it if you could select the direction of the effect of the UIAnchor: horizontal, vertical or (as it currently is) both. If that worked it would be great if you could add two UIAnchors to a single object - one for horizontal positioning and one for vertical positioning. That would allow some cool UI animations.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: nerophon on November 27, 2013, 06:31:35 AM
Nerophon: Masking with clipping can be doe by changing the shader used for the UITexture. See http://nickithansen.dk/masking-and-clipping-textures-using-shaders-in-ngui/

Ah, excellent! Thank you :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: agentsmith666 on November 27, 2013, 07:07:13 AM
Sorry but with version 3.0.6 having to "search Control" in the Project windows to find widgets is slow and painful.  Accessing the "Widget Wizard" from the menu without having to type anything and once opened can be kept opened, made it a lot faster to create UIs.  Now there's a "legacy" label next to the "Widget Wizard" which makes it seem like you're planning to move away from it.  Big thumbs down if you do.

Ugh... 
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: kenshin on November 27, 2013, 07:56:22 AM
Please, absolutely improve UIInput adding: text selection, simple multiline for textarea (without using ctrl+enter)!

Thanks
Kenshin

PS: Also enable copy/paste will be a great feature for textfield and textarea
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: kitgui on November 27, 2013, 08:40:36 AM
NGUI doesn't really handle multiple controllers at the moment.

I'm working on a local-coop game for up to 3 players where the screen is divided into 3 columns, and each player has their own menu that needs to accept input from just 1 specific controller.

There are numerous ways to work around this, at the moment we've decided to wrap UICamera and override ProcessOthers() to differentiate input devices, but it would be great if future versions took this into account :)

Thanks for the great framework Michael, you're doing a great job!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: mrobitaille on November 27, 2013, 12:03:38 PM
I've been using NGUI for almost 5 months now and I have to say that it is a great tool.

Just a couple of things:
- Better sorting algorithm in BetterList, it does 3k+ comparison for 50 elements
- Fonts in general, we are building for mobiles, so dynamic fonts are not an option and bitmap fonts, even when pixel perfect & pre-multiplied alpha, they don't always look good and down-scaling is ugly. It should be possible to have only one big bitmap font and downscale to fit the needs and saving memory by not having 4 different size of the same font in the atlas.
- Fonts effects, the designed with whom I work wanted a text glow, and I had to have the same font twice in the atlas with one of the two as a blurred version but it takes an incredible amount of space.
- A timeline system for animating the GUI would be nice (think flash timeline), I know it is a huge feature, but would be very nice  :D

Mathieu

EDIT:
- Better support of Perforce with the atlas maker, currently it ends in failure if I don't manually check out the texture files before updating the atlas because Unity only checks out the prefab file.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Antiloco on November 27, 2013, 12:06:20 PM
In UIinput ,please  add text selection.
In Textarea, use enter key for a new line (instead of control-enter).
Possibility ,in  UIPopupList ,  to change selection using index instead of only with value.
UIPanel has centered pivot point only, i think that would be useful to change pivot point ,like widget, in order to easily resizing with the parent contanier
Prevent , in UIDraggable object, drag outside of the screen.

Thanks
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: r3dwolf on November 27, 2013, 12:43:36 PM
Hello!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: laurentl on November 27, 2013, 02:52:43 PM
NGUI is a very good event and display API, but not a UI API.

For it to become a UI API it needs to manage states and transition.

So the number one grief about NGUI is the lack of state machine.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: yarbsea on November 27, 2013, 09:28:46 PM
Request UIPopup font section offer the same 'effect' setting as the UIlabel, namely the wonderful outline/shadow.

While your at it, why can't you offer us the option of BOTH outline AND shadow on text :)

THANKS!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Bradamante3D on November 28, 2013, 03:49:27 PM
I am just upgrading from 2.6.5 to 3.0.6 and it seems that the ProgressBars / Slider lost it's "centered" option, where the bar shrinks/grows to both the left and the right. If that option is really gone (instead of me just not seeing it), I'd like to get it back.
Other than that, the upgrade rocks! I haven't tested my most complicated stuff yet ...
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on November 28, 2013, 03:51:12 PM
Scroll bars still behave like that, but they won't do so at edit time. The foreground's starting size is the full size of the scroll bar: http://www.tasharen.com/forum/index.php?topic=6733.0
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Cabal on November 29, 2013, 05:03:44 PM
Hi all,

Here is a quick suggestion that may make it easier for anybody who wishes to use NGUI with OnGUI events (for instance for a debug menu)
The idea is to use the existing onCustomInput delegate function but call it *before* processing mouse inputs so we can tell NGUI to not process any input by returning false.

The comments mention using the delegate to handle things like wp7 touches so I am unclear if there is a good reason for it to be called after mouse inputs.
If not, this small change makes it very easy to layer a simple OnGUI menu on top of NGUI and have the OnGUI element "eat" the event so NGUI doesn't receive it.

From UICamera.cs   
   void Update ()
   {
      // Only the first UI layer should be processing events
      if (!Application.isPlaying || !handlesEvents) return;

      bool shouldContinue = true;
      // Custom input processing
      if (onCustomInput != null)
      {
         shouldContinue = onCustomInput();
      }
      if (!shouldContinue) return;

      current = this;
      etc.

Note: this basically only moves the onCustomInput call earlier in the function and bail out if the callback returns false (currently the delegate returns void).
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: wom on November 30, 2013, 06:12:12 PM
The idea is to use the existing onCustomInput delegate function but call it *before* processing mouse inputs so we can tell NGUI to not process any input by returning false.
...
Note: this basically only moves the onCustomInput call earlier in the function and bail out if the callback returns false (currently the delegate returns void).

This would probably also help people who need to make Unity Remote work to hook it up as custom input, as in http://www.tasharen.com/forum/index.php?topic=6583.0
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Nicki on November 30, 2013, 06:17:20 PM
Importing from Texture Packer with full rotation and everything would be a super nice thing for optimizing texture atlases. I assume the rotation is a unity limitation maybe? But their fonts seem to rotate.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: gyd on December 01, 2013, 06:33:29 PM
Could you add a easy way to Play SFXs on/under specific UI?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 02, 2013, 09:28:18 AM
Not sure what you mean, gyd.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: gyd on December 02, 2013, 10:08:10 AM
Not sure what you mean, gyd.

Sorry :(

What I mean is,
if I have a Effect, made for 3D, sparkle effect for example, and I want to place the Effect on a UI permanently( or trigger by some event, like Click ).

The Effect is hard to set to right render queue, especially when I want to place it on some UI's forward, and the other's backward, like between Button and Background.

The best way I can figure out to make it possible is using a specific shader( in fact, I need more then few shaders to do this ).

sorry again, hope I explained clear enough.


modified:
is there any way to get current renderQueue of a sprite? the best way I can find now is to modify the renderQueue of a SFX's material to be sprite.renderQueue -1/+1, to make it under/above a sprite :(
   
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 03, 2013, 09:45:24 AM
  1. UIWidget.drawCall.renderQueue + 3000
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: dominus85 on December 03, 2013, 04:15:39 PM
I subscribe to the UIGrid with pivot point.. very useful for mirrored ui's
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jingato on December 04, 2013, 01:11:11 PM
1. HD & SD Atlas building:  It would be nice to give the atlas make the option to build 2 atlases, and HD and an SD version. Right now I have to build the HD version and then duplicate the generated version and manually re-size it. I have to do this every time I rebuild the atlas so it would be nice it NGUI atlas maker could do that atomatically.

2. I really big thing I would like is a filled sliced sprite. That is, a sliced sprite that also has the same ability as a filled sprite.

3. Some type of markup system to allow you to change the font or make it bold, italic, change size, etc, all in the same label

4. Data binding

5. As I mentioned in an earlier post. Ability to use parameters in button events.

Thanks! and can't wait for uGUI!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Holdwick on December 06, 2013, 12:16:38 AM
I've got a feature request for ya.

In our game we've implemented a custom input system so that we can use many types of input(keyboard, joystick, xInput), along with player specific input.  This also includes redefinable keys, and restricting menu input to a single player.  NGUI's current input setup, specifically with GetDirection, Confirm, and Cancel in UICamera, are not quite customizable enough.  For example, you cannot bind an axis, like gas pedal, to confirm.

What would be really nice for this is a way to accept custom input, perhaps through an interface.  That way I can deal with which player is active and what device they use, and send that input to the UICamera.

Something along the lines of:
  1. interface ICustomInput
  2. {
  3.         void GetDirection (ref int vertical, ref int horizontal);
  4.         bool MenuCancelClicked ();
  5.         void GetMenuConfirmState (ref bool submitKeyDown, ref bool submitKeyUp);
  6. }
  7.  
Would work splendidly.
Thanks!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Isamson on December 06, 2013, 09:39:17 AM
First off, I just want to say thanks for all the latest updates. Here's my request:

We are currently working on a project that is controller input based and I would really appreciate if the "Draggable Panel" could use an index input to display an element within the uiGrid or uiTable nested inside a clipped Panel. What I'm looking for is to generate a list of items, for example, and be able to provide the index of the item so that the list would scroll to that specific item. Being able to set a scroll speed would be nice.

Another option could be to set a headspace for the scrolling. Let's say I have a list of 7 items and only 5 can be displayed due to the clipped panel size. The panel would not scroll until I reach item 4. From there, if I select item 5, the panel would scroll up 1 item to display items 2 to 6.

Example:
                  item 1
------         -------
item 1         item 2
item 2         item 3
item 3         item 4
item 4         item 5
item 5         item 6
------         ------
item 6         item 7
item 7
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 07, 2013, 01:02:07 AM
Have you seen UICenterOnClick? It has all the logic you need inside of it.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Dethanos on December 07, 2013, 05:35:12 PM
Could buttons automatically have their colliders resized if the button's background size has changed, i.e. when the screen size is changed.

Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 07, 2013, 06:29:38 PM
If the button is on a widget, yes. Widgets have the option to auto-resize their collider. If you put UIButton on an empty game object then no. Check the provided button controls that come with NGUI.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: dominus85 on December 08, 2013, 06:30:58 AM
When editing a value why not use the up/down arrows to make adjustments to that value? this would allow for perfect placement without having to type all over again the number
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jaz1974 on December 09, 2013, 04:56:08 AM
CLEAR EXPLAINATIONS OF EACH FEATURE, AIMED AT NON-PROGRAMMERS

Without any doubt the biggest improvement you can make (if you want to increase the user base), is to re-write the documentation so that it can be clearly understood by a NON-programmer.
It's fairly clear you are an extremely competent programmer.
However, I'd assumed that the main target audience for NGUI was those who cannot write code, or have limited programming abilities.  After all, those who can program effectively will be able to do most of this stuff for themselves.

Words like 'Class', 'Function' and 'Enumerations' don't mean much (or anything) to a lot of people who are likely to use NGUI in an attempt to avoid programming all this stuff for themselves.

You may well find you spend a lot less time explaining things to people on this forum, if you take the time to explain ALL the features of NGUI in a manner which can be understood by someone with a creative mindset.

Personally, what I'd find very useful is a scenario in which you might use each of NGUI's functionality.
I'm assuming everything that you've added, was added with at least one use in mind.

E.g. UIAnchor - explain why its there and what its useful for in non-programming terminology.   Rather than just explaining how the code works.  That's not all that useful for a designer.

Without doing this, I suspect you are selling yourself short.  There's a lot of cool things in there that are probably not being used to their full potential as they are difficult to understand.

I'd also strongly suggest creating more youtube videos showing how, where and why you'd use certain components in certain situations.

Jaz


Update :   Hah!  I just discovered your video for the new Anchoring system.   Spot On!  More of these please!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: bac9 on December 09, 2013, 10:04:14 AM
Words like 'Class', 'Function' and 'Enumerations' don't mean much (or anything) to a lot of people who are likely to use NGUI in an attempt to avoid programming all this stuff for themselves.

While more detailed documentation is always nice, I disagree that anything in this example should be explained in the NGUI docs. Knowing what a method, class or a coroutine is is an extremely basic knowlenge fundamental to practically any developer using Unity, and it should be learned/covered through official Unity docs and tutorials (or even through general-purpose docs on C# or programming in general), not re-explained by every plugin author. Doing so would be like having a racing game explain to the players what a wheel is. :)

I don't really believe in a mindset of "I'm a designer, I won't touch any code with a ten foot pole", that approach is rarely productive and usually rarely welcomed in the industry. I'm a graphic design and art history graduate, I didn't know jack about code apart from the most vague concepts a year ago, but as I have discovered, learning the very basics takes laughably little time and greatly expands what you can do.

Even supposedly designer-centric solutions like Playmaker still require a basic understanding of how code works and shower you with triggers, variables, methods, statics, loops and all the other terms - which is completely alright, as it's absolutely not some arcane knowledge.

And speaking of other example, I think the documentation explains the UIAnchor in a pretty clear manner:

Quote
Anchor script can be used for several purposes, all of which are also covered in Example 0.

  • It can make widgets appear pixel-perfect on Windows machines by applying a half-pixel offset (works only for widgets parented to the anchor).
  • If placed on an object it can be used to anchor that object to the side or corner of the screen.

Parameters / Tips
[...]

Doesn't sound very much like "programming terminology".

P.S.: ArenMook, by the way, isn't half-pixel thing obsolete now with the release of 3.0.7? Or it was just the inspector property that was removed? In any case, it's probably worth to update the screenshot on that page :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: gyd on December 09, 2013, 10:57:21 AM
hi,
About ScrollView
Is it possible to create a "loop" scroll view, for example:

|123|456 => 12|345|6 => 12345|612|
|<->|             |      |               |     |
  items in view
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jaz1974 on December 09, 2013, 07:30:30 PM
While more detailed documentation is always nice, I disagree that anything in this example should be explained in the NGUI docs. Knowing what a method, class or a coroutine is is an extremely basic knowlenge fundamental to practically any developer using Unity, and it should be learned/covered through official Unity docs and tutorials (or even through general-purpose docs on C# or programming in general), not re-explained by every plugin author. Doing so would be like having a racing game explain to the players what a wheel is. :)

Think you may be misunderstanding my point.
When I say words like 'Class' don't mean much to a lot of people....I mean they shouldn't be used.  Not that they should be explained.
If NGUI is to become more user friendly (which is what I'd expect to be one of it's core values), then the documentation should be aimed at people who don't understand programming; as well as those who do.
I'm glad to see that, with the new videos explaining the functionality of the new feature set, the NGUI guys are doing exactly that.
Not everyone cares about how a car engine works.  Some people just want to know how to drive it.

If Playmaker requires an understanding of how code works, then that's it's failing. 

I've worked in the video games industry for 15 years as a designer and have seen all kinds of toolsets.
I realise that as systems get more complicated and detailed, it unavoidable at some point you're going to get involved in something that looks like programming.  One thing I can say without exception is that all of the tools I've used have strived to avoid this wherever possible, so that the creative side of things don't get bogged down with the technical parts.

Give any designer the option of having to get involved in programming something, or being able to get on with designing something....they'll choose the same one every time.  Otherwise, they're a programmer masquerading as a designer.  ;)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: 505083367 on December 10, 2013, 04:43:40 AM
1 can have an option in widget that ignore it when calculate bounds.  i have some effects in clip panel, when i reposition the panel, the panel clip will scale to the size include those effects, this is not what i want.

2 3.0+'s raycast is using depth. so i think is there any possibility the raycast depend on sprite's pixel alpha which position i clicked on, and then i don't need add some mesh collider to my irregular sprite button.

3 UIRoot scale base on height.  but it's necessary have an option base on width or base on both(internal or not), like  UIStretch.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Yukichu on December 10, 2013, 10:23:31 AM
After some consideration, I do have a request for improvement...

The ability to chose an imported sprite to be a "Diced Sprite" in the atlas.  I (and I would think possibly others) have some large sprites that could be reduced in size considerably if they were diced.  Creating a sliced sprite out of them won't really work, so they are currently like 256x256 or larger sprites in my atlas (UI outlines that look very specific and cannot be sliced.)

Yeah, like most everyone else in here my response is, "Improving NGUI means improving my project specifically!"

If this feature never happens, I'll be fine.  It would be nice though and save some considerable space on the atlas size at the expense of a few more triangles.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jaz1974 on December 10, 2013, 10:43:55 AM

1.  The ability to drag objects out of a scrolling table.

...maybe its already there?  Wasn't the last time I looked.  Would be great if it is.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Hawkins on December 10, 2013, 05:40:06 PM
Would you like to make some suggestions for future versions, hope you like: Sorry for my typos, I speak French and am learning English now.

1 - Revamp Localize

I saw that some people here also use the Locate unfortunately only changed the system default translation by another, because the NGUI does not recognize CSV, it would be great if he would accept this format, and go beyond incorporating a few more features, will give an example:

(http://imageshack.us/a/img401/3302/mnkf.png)

Standard format for the new CSV (is a suggestion), we have the first column with the key of the item, the second with a description of that item, and from the third onwards would translations.

Using UnityEditor own, did the prototype of the modernization of some components:

(http://imageshack.us/a/img819/756/xc1z.png)

Here we would have. CSV file, and could select which is the column that stores the keys, which stores descriptions and below we could choose, add and remove languages ​​(it does not alter the CSV), first on the list would be the default language, here we choose which column would be designated for each language.

And here is an updated version of the component to use a translation in UI components like label, button, etc ...

(http://imageshack.us/a/img689/5479/mnvw.png)

As you can see he was getting and displaying the data from the CSV so we can verify if that is the translation we want to use:

(http://imageshack.us/a/img703/2818/4ybh.png)

In the future, data from the translations could be edited for that component itself.



2 - Spinner

As we often deal with values​​, and sometimes we need to change the value every few units, it would be very good, implement the spinner to the editor values​​.

(http://imageshack.us/a/img440/3660/bn9y.png)



3 - Snap Lines

Another nice addition would be adding gridlines to help when we try to align components as well as Visual Studio does:

(http://imageshack.us/a/img600/6787/r9yw.png)



4 - Active/Desactive Component

Whenever I create a menu or interface using Ngui, I create a component to enable / disable GameObject, so it becomes easier to choose which "Windows / Components / Labels" I want to hide / show when the player clicks on a button, I think whether this component by default in Ngui would be wonderful, and others also have access to it, and not need to create components for it or writing code:

(http://imageshack.us/a/img809/6250/1u00.png)



6 - Tab Index

And lastly, my suggestion is to implement a behavior similar to the TabIndex (HTML), where we could define what the order of the components when the player pressed the Tab or utilizes the Joystick.



Well here are my suggestions are only a few ideas, which I think would add a little more easily this wonderful tool that is Ngui. I hope ArenMook like.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jaz1974 on December 10, 2013, 06:49:10 PM

4 - Active/Desactive Component


+1 for this suggestion.   
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: mythos on December 10, 2013, 07:55:37 PM
Using a namespace would be nice. I just purchased and imported nGUI for the first time, and I'm getting class conflicts in scripts where I don't need nGUI.
Just my $0.02
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: DarthMH on December 10, 2013, 08:09:28 PM
1 - Revamp Localize
(http://imageshack.us/a/img819/756/xc1z.png)

(http://imageshack.us/a/img689/5479/mnvw.png)


This is all I desire more in NGUI Localization System. I hope that in future versions implement some of these features.


4 - Active/Desactive Component
(http://imageshack.us/a/img809/6250/1u00.png)

And as the jaz1974 I also give my vote to the "Active / Deactivate Component"
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 10, 2013, 10:20:33 PM
1.  The ability to drag objects out of a scrolling table.

...maybe its already there?  Wasn't the last time I looked.  Would be great if it is.
http://www.youtube.com/watch?v=B66xhIvYF00&feature=c4-overview&list=UUQGZdUwzE8gmvgjomZSNFJg, around 32:40 mark I make it possible to drag & drop items out of a scroll view.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: thormond on December 11, 2013, 05:09:51 AM
How about using 2D colliders and Physics2D.OverlapPoint instead BoxCollider and Physics.Raycast for mouse events? I know 4.3 is relatively new but that adjustment would be more convenient and faster (for overlapping colliders it could prioritize Z from transform, then layer of the panel and then sorting order of the widget attached)

Also it would be good if Unity 2D layers/sorting orders were going in par with NGUI's panels and depth (eg: I have animations done with vanilla unity Sprites and positioning them in hierarchy of NGUI elements is hard without converting each Sprite to NGUI's 2D Sprite or using shaders)

*edit: you cannot animate NGUI's 2D sprite component
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: zippo227 on December 11, 2013, 11:47:34 AM
First of all, I really like NGUI, and I appreciate all of your continued effort to make it more user friendly.

All NGUI files should be able to compile inside of MonoDevelop. Things like default parameters in C# typically do not compile in Mono, even though they compile in Unity. I always test by building in Mono first to track down obvious errors and warnings, but now, I have to make sure to close NGUI files because some of them have errors.

I would like for most functions to become protected by default. I create classes that inherit from NGUI classes to keep from losing my changes when upgrading to the latest versions. This forces me to manually change some NGUI functions to be protected instead of private. For instance, I have to make UIInput's Start function protected. Then the inherited class makes a "new void Start()" and calls base.Start();

It would be nice if the only times I had to modify my inherited classes were to account for a renamed class (like what I had to do with UIDragScrollView). For that class (and others) I need to add an OnHover function to keep my game's camera from responding to the scroll wheel.
Title: Tweens
Post by: luisdiv on December 11, 2013, 01:29:42 PM
I very much like using TweenPosition and other tweens.
What I don't like is the fact that whenever I add the component to an object, it's position resets to 0,0,0.
I wish it would stay the same.

Thanks
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Vaupell2 on December 11, 2013, 03:47:25 PM

More importantly still... what frustrates you in NGUI? What makes you go "AAAARRRGHGHHHH!!"? I myself tend to rage quite a bit IRL (mainly related to Mecanim lately... ugh!), so I am quite guilty of hating the system because I don't understand it. So if something is driving you nuts and you want it changed / explained, feel free to vent here and I will do my best to do something about it.


The   UIToggle functionallity and setup!
I imagine that that is the most common use for toggle buttons if any use..
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: hellobard on December 11, 2013, 05:30:25 PM
Love the new updates in NGUI 3.07, some really great advances happening here.

A lot of people have chimed in on this as well, but here's my vote too:

- Automatic multiple-resolution altas generation and handling of all different resolutions on different devices for pixel perfection
 Right now I have to use Retina Pro to get pixel perfection, and that is a great plugin but it's really something NGUI should be doing.
Even with this great plugin, I still have to manually send updates to update anchor sizes so that they fit the specific device. Also, for disabled panels that suddenly come into play, I have to manually run a script that updates the sprites to pixel perfection.

Having this handled by NGUI automatically would make me scream "ARRRRRGHHHHHHHH!!!" a lot less, which I think would be great news to my family and neighbors).
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 12, 2013, 02:29:09 AM
How about using 2D colliders and Physics2D.OverlapPoint instead BoxCollider and Physics.Raycast for mouse events? I know 4.3 is relatively new but that adjustment would be more convenient and faster (for overlapping colliders it could prioritize Z from transform, then layer of the panel and then sorting order of the widget attached)

Also it would be good if Unity 2D layers/sorting orders were going in par with NGUI's panels and depth (eg: I have animations done with vanilla unity Sprites and positioning them in hierarchy of NGUI elements is hard without converting each Sprite to NGUI's 2D Sprite or using shaders)

*edit: you cannot animate NGUI's 2D sprite component
I can't use 2D physics because:
1. It will break backwards compatibility.
2. It will mean that everyone now has to upgrade to Unity 4.3 or higher.

As for animating the 2D sprite: you can. Animate the 'nextSprite' variable.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 12, 2013, 02:31:15 AM
First of all, I really like NGUI, and I appreciate all of your continued effort to make it more user friendly.

All NGUI files should be able to compile inside of MonoDevelop. Things like default parameters in C# typically do not compile in Mono, even though they compile in Unity. I always test by building in Mono first to track down obvious errors and warnings, but now, I have to make sure to close NGUI files because some of them have errors.

I would like for most functions to become protected by default. I create classes that inherit from NGUI classes to keep from losing my changes when upgrading to the latest versions. This forces me to manually change some NGUI functions to be protected instead of private. For instance, I have to make UIInput's Start function protected. Then the inherited class makes a "new void Start()" and calls base.Start();

It would be nice if the only times I had to modify my inherited classes were to account for a renamed class (like what I had to do with UIDragScrollView). For that class (and others) I need to add an OnHover function to keep my game's camera from responding to the scroll wheel.
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.
Title: Re: Tweens
Post by: ArenMook on December 12, 2013, 02:31:49 AM
I very much like using TweenPosition and other tweens.
What I don't like is the fact that whenever I add the component to an object, it's position resets to 0,0,0.
I wish it would stay the same.

Thanks
That's a bug. I will fix, thanks!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: thormond on December 12, 2013, 04:35:51 AM
As for animating the 2D sprite: you can. Animate the 'nextSprite' variable.

Looks like I've been using 3.0.6 f3 and nextSprite was introduced in 3.0.6 f6 so as the matter of fact: I couldn't  : D

(http://gyazo.com/1c2329e2e8f5d2bffbca9ce140c1b54f.png)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: hlx on December 12, 2013, 10:20:34 AM
Hello Michael,

I wish an improved UIpanel script that allow the user to nest a clipped panel in an other one, like a scroll view inside an other scroll view...

Cheers,

Hlx
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jaz1974 on December 12, 2013, 07:32:29 PM
http://www.youtube.com/watch?v=B66xhIvYF00&feature=c4-overview&list=UUQGZdUwzE8gmvgjomZSNFJg, around 32:40 mark I make it possible to drag & drop items out of a scroll view.

Fantastic stuff!!
Love these videos.   Keep up the great work.

Jaz
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 13, 2013, 05:50:20 AM
Hello Michael,

I wish an improved UIpanel script that allow the user to nest a clipped panel in an other one, like a scroll view inside an other scroll view...

Cheers,

Hlx
Random thought just hit me.... this is already possible. You just need to use stencils. I'll see about adding a tutorial on this in the near future.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Cabal on December 13, 2013, 10:39:39 AM
One suggestion for tweens when you want to create an animation that, for instance, blinks three times and then stops: the UITweener class could a "count" variable that can be specified in the editor to tell NGUI how many times to play the given tween. The count parameter would be decremented every time the animation completes and the script would only disable itself when count reaches 0.

Example 1: blink three times
style = loop
count = 3

Example 2: fade in and out once
style = pingpong
count = 1

This would simplify creating simple tweens with predictable behaviors.

Thoughts?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Yukichu on December 13, 2013, 01:57:40 PM
All NGUI files should be able to compile inside of MonoDevelop. Things like default parameters in C# typically do not compile in Mono, even though they compile in Unity. I always test by building in Mono first to track down obvious errors and warnings, but now, I have to make sure to close NGUI files because some of them have errors.

Build with Unity.  Just switch windows to the Unity Editor and Unity will compile it.  I used to think 'make it compile in MonoDevelop' too for everything; however, handicapping the development of something because MonoDevelop doesn't support it... but Unity does... just makes no sense.  Use Visual Studio Express (it's free), or use Unity to compile things.  I only use Mono to attach a debugger for the rare times I need that functionality.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 13, 2013, 05:54:28 PM
@Cabal: You can do all this by simply creating that pattern in the Curve field.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ryan on December 13, 2013, 07:54:40 PM
I would love an event that we could hook into to be notified when a widget or rect's size and position have changed.  The new anchor system is great for making UI's the fit whatever screen dimensions you've got, but I have several cases where I want to do something more complicated within a particular region of the UI based on the space available.  This is stuff that I don't want to recalculate every frame, and I'd rather not have to poll to see if the widget has changed, either.

Maybe there's a more general solution that can work with the new anchor system to allow more powerful layouts to be created...
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 14, 2013, 12:39:52 PM
Done. UIWidget.onChange is now in the Pro repo.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: KirbyRawr on December 15, 2013, 02:10:57 PM
New Validation system for UILabel , i created one specifically for input of the names, without symbols but with accents supports:

  1. else if (validation == Validation.NameWithSymbols)
  2.                 {
  3.                         char lastChar = (text.Length > 0) ? text[Mathf.Clamp(pos, 0, text.Length - 1)] : ' ';
  4.  
  5.        
  6.                         if (ch >= 'a' && ch <= 'z')
  7.                         {
  8.                                 // Space followed by a letter -- make sure it's capitalized
  9.                                 if (lastChar == ' ') return (char)(ch - 'a' + 'A');
  10.                                 return ch;
  11.                         }
  12.  
  13.                         else if(!(ch >= '0' && ch<= '9') && ch !='?' && ch !='!' && ch !='<' && ch !='>' && ch !='\u00BF'
  14.                                 && !(ch >= '\u007B' && ch <= '\u00BF') && !(ch >= '\u0020' && ch <= '\u0040') && ch != ' '
  15.                     && !(ch >= '\u02B0' && ch <= '\u036F')
  16.                                 && !(ch >= '\u005B' && ch <= '\u0060')){
  17.                         return ch;
  18.                         }
  19.                 }
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 15, 2013, 04:31:46 PM
You can just set UIInput.onValidate to your custom validator. No need to modify UIInput itself.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: kitgui on December 16, 2013, 02:42:13 PM
Quote
- NEW: Enabling/disabling widgets no longer affects other panels.

Sweet! :D Thanks Mike
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jsbanwjly on December 17, 2013, 02:48:27 AM
hi, i need repeated button.  process "onPressed".
thank you.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: hlx on December 17, 2013, 04:41:38 AM
... this is already possible. You just need to use stencils. I'll see about adding a tutorial on this in the near future.

Oh yes, please. I need some explanation since I would like masking a scroll bar (and his content) by a (high level) parent panel object. By stencil, I guess that you are talking about a texture widget that have an alpha channel that should be the parent of the hierarchy to mask. Am I right ?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ChrisR on December 17, 2013, 06:00:07 AM
You might've already added these Aren (we're still on 3.0.5 ourselves, haven't been able to upgrade in a while) but this is some stuff we've found useful and added ourselves:

UIImage Button: added the option to set a disabled state sprite.
UIButton Color: added a disabled state colour.
UIPopupList: Added an option to adjust the speed of the TweenPosition and TweenColour.
UIPopupList: Added the option to offset the position of the popup box - to compensate for the sliced sprite bound.
UIToggle: Added a "Can be none" option when a toggle is part of a toggle group. For us, this was useful in avatar icon select - once a user had selected a picture, they weren't able to have no picture, so we added this to allow that.

UIInput: I think we added a custom validation type for Email. Not sure if it's clever enough to detect a bad email format, but it removes the illegal characters.

Minor things, but they were helpful!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ChrisR on December 17, 2013, 06:01:29 AM
Random thought just hit me.... this is already possible. You just need to use stencils. I'll see about adding a tutorial on this in the near future.

Also I'd love to see a tutorial on this, when you get the time. :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: kitgui on December 17, 2013, 03:16:10 PM
As far as I know, stencil buffering is disabled in unity free, but it can be simulated with the use of multiple cameras
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: syslord2k2 on December 18, 2013, 11:30:25 AM
I already added this myself but the updates keep overwriting it:

Delay for the UIButtonActivate because you sometimes want to do something to the button first (shake it or so) and activate/deactivate things after the tween. I know that you could use the notify feature to achieve the same functionality but that means writing a script for it etc... :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jsbanwjly on December 18, 2013, 10:38:44 PM
can UIToggle have a delegate function that i can return false or true to determine whether set new value. sometimes i need a condition check.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 19, 2013, 11:59:57 AM
UIToggle.current.value
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: g2mediagroup on December 20, 2013, 02:20:50 PM
I would have to sum it all by saying, new UnityGUI/NGUI need font handling/formatting like all basic word processors have. Better control of kerning, line spacing, resizing and an easy way to apply textures to dynamic fonts. (gradient tool would do the trick for me ;) ).

That sums up my AAaaaaaaaaggggghhhh!!!! factors.

My .02
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: gyd on December 24, 2013, 03:21:54 PM
1. ScrollBar in Slider style :

I created a spider/web style scrollbar, but the scrollbar would be auto resized when OnValueChanged.
so i created a slider, use the web sprite as foreground, and the spider sprite as thumb, and also added a script to receive OnValueChanged event. with the script, I could set the scrollbar value to the slider.
In the 3.0.7, a scrollbar foreground is required, so i should have to add a empty widget for the scrollbar, but the widget is useless!


2. Multi Inputs Tweens:

Sometimes we need to tween something with multi inputs, ex: tweenPosition by some points, instead of from-to.
it will be fantastic if some built-in tweens of NGUI support multi-inputs.

thanks
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: stylophone on December 25, 2013, 01:53:40 AM
Hi,

I'd like to see if add "Manual Width" in UIRoot fixed size as well...since sometimes I may want to scale the screen by "width" but not always by "height"...
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: devomage on December 25, 2013, 05:25:58 PM
several months ago i posted about adding an up/down button to the top/bottom of a vertical scrollbar.  it'd be great to have this as a canned control.

example here:

http://www.tasharen.com/forum/index.php?topic=4593.msg22086#msg22086 (http://www.tasharen.com/forum/index.php?topic=4593.msg22086#msg22086)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: dominus85 on December 27, 2013, 08:33:23 AM
I saw you will add a new Sliced and Tiled sprite in 3.0.8

Would it be possible to add a Sliced and Filled sprite? Would make use of that in my current project. Cheers
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 27, 2013, 03:57:06 PM
It's a part of the same sprite. You can choose what happens with each piece of the sprite. Nicki made it.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Nicki on December 29, 2013, 05:41:06 PM
How exactly would you want sliced+filled to work? Just so you could have a float 0-1 for each axis, that clips the sprite? I suppose that could be added to the advanced sprite type. Lemme mull it over - I can only add it when I get home from new years though. :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: John.Bergman on December 31, 2013, 02:29:04 PM
How about a few more prefabs for things like Toggle Buttons (Radio Button Groups), Windows, and the like.  I am still new to NGUI, but I really like what I see so far, and the responsiveness is fantastic!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Failtruck on January 02, 2014, 08:00:10 PM
I'd like to see some sort of animation timeline manager (like flash).
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: John.Bergman on January 03, 2014, 05:01:00 AM
I'd like to select multiple items and then be able to affect their Pivot points and alignment.  It takes too long to right-align labels and left-align controls when laying out forms.

Unless anyone knows of an easier way... I messed around with Grids and found that just too cumbersome as well.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 03, 2014, 05:54:49 AM
You can select multiple widgets and change their pivot at once. When you drag widgets, they also snap to neighbours, so aligning labels to siblings shouldn't be an issue.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Hawkins on January 04, 2014, 06:52:43 AM
I think a suggestion in adding UIButton to an option to default status, ie I can choose which default state of a button, if it is already enabled or disabled by default. It could be a Toggle. Currently, so I let the behavior of a button as disabled, I have to create a script, attach to the button and off it.

Also I think it would be easier for users to manipulate the uitable if he had a behavior somewhat similar to the NGUI extension of this video:
https://www.youtube.com/watch?v=MK7dNqC2VFM&hd=1 (https://www.youtube.com/watch?v=MK7dNqC2VFM&hd=1)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: John.Bergman on January 04, 2014, 06:53:25 PM
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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: John.Bergman on January 05, 2014, 06:23:12 AM
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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 05, 2014, 09:13:52 AM
@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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Rick74 on January 05, 2014, 12:19:31 PM
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?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Rick74 on January 05, 2014, 12:24:17 PM
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.   ;)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Nezabyte on January 05, 2014, 04:10:40 PM
It would be great if NGUI scripts were in their own namespace; helps avoids conflicts with other assets.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 05, 2014, 05:20:55 PM
@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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: zippo227 on January 06, 2014, 12:03:29 AM
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  :o
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: indiefreaks on January 08, 2014, 10:06:29 AM
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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 08, 2014, 01:49:46 PM
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?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: indiefreaks on January 08, 2014, 07:12:32 PM
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 (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 ;)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ryan on January 09, 2014, 02:27:39 PM
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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: stapledon on January 10, 2014, 11:37:47 AM
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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: amaranth on January 10, 2014, 05:57:08 PM
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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 10, 2014, 06:22:31 PM
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.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: voncarp on January 13, 2014, 04:50:21 AM
I've been using NGUI for nearly two years.  What direction do you think users should go?  Packages like NGUI take quite a bit of time to get familiar with.  It sounds like because of your contract, your limited in what improvements you can do for NGUI. 

Should long time users brace for Unity's next GUI or continue to add NGUI to our projects?

Since your involved in improving Unity's GUI what do you suggest we do?  Which one is better?  Which one will be better next year?  I've found it very inefficient to implement several different GUI solutions for a project.

Like many others, I am huge fan of NGUI.  I've spent countless hours working and learning from it.  However, it seems like your hands are tied.  As odd as it seems, Unity's new GUI seems like a competitor and your tasked with making the competitors GUI more efficient.  If your unable to further grow and expand NGUI because of your contract limitations, it almost seems like all NGUI users will eventually be forced to convert over to Unity's new GUI.

You seem to be in a difficult situation trying to balance your responsibilities to Unity and NGUI.  But, your longtime users now have this cloud of uncertainty on whether there is a sustainable future for NGUI in our future projects.  Is there a best before date now attached with NGUI?   How about HUD text?  Is that going to be usable with Unity's new GUI?

We are going to continue to make games regardless.  But, since you have direction of Unity's GUI and knowledge of the future of whats in store for NGUI, what GUI should we implement in our games to come?

Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 13, 2014, 05:22:03 PM
I don't work at Unity anymore, so I am not limited in any way. I was in Unity for 13 months, helped with the UI system, and then parted ways. My interest lies more in game dev than tool dev, even though I seem to be fairly successful in the latter. I am not a big fan of large teams/companies in general, although I have to admit people at Unity were pretty amazing, and it's a fantastic company to work for.

I plan on re-starting Windward's development in a few days, turning it into a completely different game in the process, and developing NGUI and TNet along the way.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: amaranth on January 13, 2014, 06:52:51 PM
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.

Fantastic! Even later is better than never.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: McSwan on January 14, 2014, 12:25:30 AM
Have the example sprites already extracted so we can quickly build custom atlases. Not a big change but a nice one.

Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on January 16, 2014, 06:16:22 PM
I like very much the new layout system but we need:

- The circles that we see in the scene view should be draggable and also mantaining shift or alt it should scale from center (like photoshop).

- The UIWidget aspect ratio should have a cropping option (I think that it's only possible for UITexture moving UVs, UISprites it's impossible because they share the same material).
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: charmandermon on January 17, 2014, 04:15:59 PM
I have been using NGUI for 2 years now, I love it.

I have been using DFGUI now for 2 months, I love it.


I really wish in my heart of hearts that you guys would consider working together.  There are some really great features in both systems.  It sucks having to choose.  Will you buy him out and hire him on the team? Please Please Please?

Things I absolutely love about DFGUI are:
The intuitive in scene layout system;
Selected item preferences (makes it feel more like visual studio);
The anchoring system;
Panel system;
A proper focus system (i dont want to mess with the effing z or depth);
A real text input box with real carret that has all the features you would want in a standard text input;
More controls ( like the tab system) (i dont like having to create them from scratch in NGUI and waste many many many hours);



Things I absolutely love about NGUI are:
prebuilt controls with base art(i dont like having to create a new button and assign every freaking sprite every time);





I have one more request that is so needed.  I absolutely can't stand this obsession with data binding, it is a waste of time and always causes issues.  I also hate how events are handled in both ngui and dfgui.  What I would like to see is to be able to uniquely identify a button or label for instance in the inspector with some kind of string id.

Then anytime that button is used it broadcasts its events globally and it doesn't care who is subscribed or listening to the event. And more importantly it doesnt have to have a script on its own item to do something.  This idea is incredibly important for buttons and other items created at runtime.

To listen for the event you would have a method that gets called in any script you want as long as the id of it matches the id on the button. Similar to visual c#

private void Button2_Click(object sender, RoutedEventArgs e)
{
    // Add code to perform some action here.
}



In all honesty i am not even sure if global message events without being manually hooked up are even possible.

Thanks for your time, keep up the hard work!


Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: drawmaster77 on January 17, 2014, 04:28:48 PM
I've been using NGUI for some time now. While its great for designing a simple UI, I feel like there is a lot of room for improvement in things like draggable panels and UITable/UIGrid. It's either overly complicated or there are bugs in there. Here are few examples: These are just few things that come to my mind at the moment. Otherwise its a great gui system.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: wom on January 20, 2014, 03:04:05 AM
Support for 3D object clipping in scroll views.
It keeps coming up in the support forum and you usually tell people to use a render texture.  But often you also suggest that people can write their own 3d clipping shader using yours as a starting point.

How about at least including a simple diffuse/unlit shader that supports clipping 3D meshes?
I reckon it would make for some cool possibilities, like using a large cylinder inside a scrollview to implement a circular scrolling list - that kind of stuff.
I guess the input system would need to know about the objects if I wanted drag to work with it.. though you could work around it be just sticking a rectangle behind objects to drag/rotate them.

Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Lotti on January 20, 2014, 10:20:21 AM
please please please please change your private variable to protected!

E.G.: i can't extend the label to add custom effects because all instance variable are private! so i have to duplicate code and update it by myself when a new release is out.

thank you!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: closcan on January 20, 2014, 02:53:09 PM
An integrated playmaker support!
That's a top list wish!!!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on January 21, 2014, 02:55:43 PM
please please please please change your private variable to protected!

E.G.: i can't extend the label to add custom effects because all instance variable are private! so i have to duplicate code and update it by myself when a new release is out.

thank you!

+10000

It's common sense...

You need to make your classes extendable...
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: 3d03 on January 22, 2014, 04:28:12 PM
Please add "number of current step" field to UISlider. I have tried to implement this info by myself, but there is problem in converting float types to int:


float step = 1f / slider.numberOfSteps;
numberOfCurrentStep = (int) (slider.value / step);


it will work but generates wrong results, in some cases it pass some numbers. I mean that sometimes value goes like   1,2,3,4,6 (if numberOfSteps is 6).

Sorry for my english
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Nezabyte on January 25, 2014, 08:46:38 AM
- Max characters per line for a UILabel

- Build-in support for tooltips to stay on the screen. I managed to achieve this by copying some code from the draggable object script, though it's slightly wonky for some reason.

- Resolved this with a derived UITooltip but would be nice if it was already built-in - if the game object it's hovering over suddenly gets disabled or destroyed, make the tooltip disappear as well. For example, I hovered over an item in inventory to view tooltip and pressed "I" on my keyboard to quit the inventory screen (panel gets disabled). the tooltip stays at the exact spot and is visible until I try to hover over a different game object that triggers the tooltip.

- A way to terminate the OnDrag event after it starts. for example, I have a ship hardpoint with equipment that I allow the user to switch out with other equipment, but I disallow the user from taking the equipment out. with my current implementation, I'm able to prevent the user from moving it, but the error sound plays continuously until I stop dragging my mouse around with left-button held down.

- In the quest log example, I noticed the text shrinks away via scaling when you collapse a quest title. would love the option of it just rolling back in and having the text clipped instead.

- A tutorial video dedicated to tweening tips and tricks. one thing I'll be implementing at some point is tweening icons within a grid (e.g. status effects). I'm imagining it'll involve a combination of tween scale, position, and perhaps alpha (icons quickly appear and slide into their grid positions).
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Wahooney on January 27, 2014, 03:53:16 AM
Improved text markup scope, we already have colour, but it would be cool it we also had:

* Text size
* Effect/gradient markup, ie. Only add an outline to certain words in a sentence
* Bold, Italic, etc.

At a stretch:
* Font face
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 27, 2014, 07:05:09 PM
You can already have bold, italic, underline, strike-through as well as sup/subscript. Check the UILabel documentation.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Wahooney on January 28, 2014, 04:25:40 AM
You can already have bold, italic, underline, strike-through as well as sup/subscript. Check the UILabel documentation.

Ah, I thought those were per label. I'd still like the rest though ;)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Asmolicious on January 29, 2014, 12:35:41 AM
I'm a professional UI games developer and I'm using NGUI for a personal project. Great work!

I've been getting to grips with NGUI.

Being able to extend existing classes would be great.

For your button delegates, adding support for basic types (bool, int, float & string) as a parameter would be great. I find I have to have a function for each button which often just sets an int / enum and is funneled to a main button press function.

Motion is a very important part of UIs for me, having the ability to define a group of tweens such as transition in / out and being able to call them would be a great core feature.

Thanks!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Wahooney on January 29, 2014, 10:19:05 AM
Request from one of my colleagues I thought I'd throw out there. Rotation of the sprite in it's local coordinates, the way that sprite sizes are now internalized.

This means that the sprite's transform orthogonal directions are unchanged by the visual rotation, this can be achieved with parenting, but it does muck up your hierarchy a bit.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 29, 2014, 10:22:57 AM
@Asmolicious: UIButton.current tells you what called the On Click function. No need to have many functions. Same with toggle (UIToggle.current), input (UIInput.current), camera (UICamera.current), etc. All NGUI classes are set up the same way. The 'current' value is set right before a callback.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ryan on January 29, 2014, 04:26:35 PM
Motion is a very important part of UIs for me, having the ability to define a group of tweens such as transition in / out and being able to call them would be a great core feature.

+1 to that.  I have a hard time deciding whether or not to have UI artists put tweens into the UI prefabs, for fear that an engineer will tween something from code, overwriting what the artists put in.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 29, 2014, 11:10:06 PM
You can also use the Unity's animation system if tweens are not complex enough for your liking. CTRL+6 and start recording.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: 2cat on January 30, 2014, 08:27:34 AM
I just started exploring NGUI 3x for our new project and although there's many a great addition I do think some stuff could be improved/added.

-The handles for widgets can only turn on or off. I personally really like the scale and even rotate handles, but I really hate how I can't use the move gizmo to only move over the x or y axis. Dragging via the transform box is just a pain in the butt as well. Would love an option to disable certain handles instead of only being able to turn all on or off.
-Tween Height and Width, but no "combined" script. It feels like a waste to have to reference to two scrips each time I wish to scale, instead of one.
-Attaching a button script on a widget doesn't automatically add a collider and there's no option for an imagebutton(you can still of course find it in the scripts folder but still..)
-The legacy widget tool says you can search for "Control" and add it to your scene but there's nothing that contains the name "Control" in my project folder when using the latest NGUI from the asset store. I can't say it works like it, but I like the widget tool because you float the window anywhere and create stuff on the fly without having to browse trough menus. Would love to know where I can find control and find out what it does.
-No more hotkeys for atlas maker ;_;

All the changes take a bit getting used to but mostly it's all positive. I hope all the above is something you can agree with and ends up on your todo list, it would greatly benefit myself and I hope it will others as well.

Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 30, 2014, 12:18:53 PM
If you can't see anything named "Control", then you didn't import the Examples folder.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jingato on January 30, 2014, 01:53:32 PM
@Asmolicious: UIButton.current tells you what called the On Click function. No need to have many functions. Same with toggle (UIToggle.current), input (UIInput.current), camera (UICamera.current), etc. All NGUI classes are set up the same way. The 'current' value is set right before a callback.

That is helpful, but most of the time having a reference to the button doesn't give much. If you are creating a scroll  list of buttons for example you would want to know which index you pressed which means you either need another script on the button which tracks the buttons index or you have to use the name of the gameobject to keep track of it, which I don't like. It would be nice if the buttons on click event could pass in parameters like and int, string, or enum. That would also be helpful when creating static UI so you can have one function for a set of buttons and pass in a parameter set in the inspector.

this is a pretty important feature that is needed IMO.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on January 31, 2014, 12:29:10 PM
Yes, but what would set those parameters, exactly? Events are generic. They don't know anything about your buttons or where they come from.

You could simply name your buttons properly. Or attach a data script:
  1. using UnityEngine;
  2.  
  3. public class MyButtonData : MonoBehaviour
  4. {
  5.     public int buttonIndex = 0;
  6.     public string someCustomValue = "abc";
  7. }
...then all you need to access it in your OnClick callback is:
  1. MyButtonData data = UIButton.current.GetComponent<MyButtonData>();
  2. Debug.Log("Clicked on button " + data.buttonIndex + " with value of " + data.someCustomValue);
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jingato on January 31, 2014, 01:30:31 PM
Yes, but what would set those parameters, exactly? Events are generic. They don't know anything about your buttons or where they come from.

You could simply name your buttons properly. Or attach a data script:
  1. using UnityEngine;
  2.  
  3. public class MyButtonData : MonoBehaviour
  4. {
  5.     public int buttonIndex = 0;
  6.     public string someCustomValue = "abc";
  7. }

...then all you need to access it in your OnClick callback is:
  1. MyButtonData data = UIButton.current.GetComponent<MyButtonData>();
  2. Debug.Log("Clicked on button " + data.buttonIndex + " with value of " + data.someCustomValue);


That's just the thing I'd rather avoid though. I would rather just have a method like OnItemSelected(int itemNumber) and in the inspector select the method from the drop down ans enter the number. I attached an example of this around page 2 of this thread I think. Or maybe just have an Object field on the UIButton that we can set some arbitrary data to.

Another thing I really would like to see is some improvements to the new anchor system. I found the new system a bit confusing but I'm starting to understand it now. I think it really lacking the ability to set you're anchors as percentages instead of pixels. Unless I'm just missing something. For example, I wand to have a group of labels placed horizontally in a row and have them evenly spaced based on the screen width. I can't seem to find a way to do it.

**EDIT** I figured out how to layout the buttons evenly by using custom as the anchor choice. It's not very cleat that that's what it does though and hard to figure out how to use properly. Plus if you decide to add another item later you will need to go over all the other items and update there anchor values to fit the new one in., which which makes it a pain...I could write code to adjust all the anchors at runtime, but If I'm doing that then I mine as well just position them myself.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: KyleStaves on January 31, 2014, 03:56:28 PM
Is the Widget Wizard being abandoned/depreciated? I kind of hope not (as I don't like having to pull the Examples in to every project) - if so it would be good to know so I can be sure to pull examples in and start using the new approach.

If not would it be possible to get the UIImageButton creation updated so that the UIImageButton script is on the Sprite and not as a parent of the Sprite? The default method of creation (collider / ImageButton script on parent, sprite and label as children) doesn't work well with the new anchoring system / collider maintain size methods.

Thanks either way!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on February 01, 2014, 01:29:35 PM
You can set the UIImageButton's 'target' to be the sprite itself. In fact it does just that on its own if you leave it as 'null'.

I'll be removing that script in the future though. It will become a part of UIButton.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Anomalous Underdog on February 03, 2014, 12:17:07 PM
I did my best in reviewing this thread but apologies if I missed anything & post something that's been addressed already.

I've used NGUI (an old version) in a released game already so I have a little bit of experience with it. I have to say though that most of what I learned is only through trial-and-error. The guide in this website (at least last I checked) seemed to be for an older version. And most of the tips and tricks could only be found by looking through forum posts.

The video tutorials are nice, but we have slow Internet connection here in my country that it's not ideal.



UIButton has event for OnClick in what seems to be an entirely new system (dropdown box to choose which function to call)

However it only has event for OnClick. When I need to listen to OnPress and OnRelease of a button I need to use UIButtonMessage. It's kind of a redundant component. I'm guessing this is due to some transition.



Data binding example use case: bind my character's health to a progress bar's (i.e. health bar) value (complete with tweening animation for the bar's width & particle effects, when the player's health value changes).

Imagine doing that without coding, or little coding that you need to write at initialization only, without having to write a new class for every little thing you come up with. The point is faster, rapid ways to prototype GUI designs for a game. Something you could let GUI designers (who have little to no knowledge in coding) in your team dabble at for experimentation.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on February 04, 2014, 03:13:45 AM
To get events for OnPress, OnClick, etc -- you can either write scripts with those functions, or attach UIEventTrigger to your button.

The updated NGUI documentation page is here: http://www.tasharen.com/forum/index.php?topic=6754.0
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: mvi on February 05, 2014, 10:47:48 AM
A recent update added support for bitmap fonts to vary their font size. However this means whenever you drag a different bitmap font onto a label it keeps the old font size, so we have to manually put in the new font size. The previous workflow worked really well as we had different sized fonts and all that was needed to change font was a drag and drop, which made font replacement a breeze. It would be nice if the default behaviour was to adopt the new font's default size (maybe only if the current font size matches the previous font, so that people who customise the font size get it preserved, but people that don't get pixel perfect from the drag and drop.) Alternatively, the Label inspector could have a pixel perfect mode and only if that is disabled is customisation of the bitmap font size possible.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on February 06, 2014, 12:32:06 PM
Labels and word wrap

There are times were it breaks words like this:

"Lorem ipsu
m dolor sit amet"

Could you make configurable? So that it breaks by word or by characters.

Anchoring and aspect ratio

I don't understand why if you set other option than "free" you can change the aspect ratio. I can understand for sliced or tiled sprites but no for UITextures or simple sprites. If I want to adapt to a "container" keeping the original aspect ratio what should I do?

Cropable textures

It would be nice if we could scale and crop UITextures using the new anchoring system. For example a dynamic carousel that has different images of different aspect ratios.

Grid and Table improvements

I think that they are getting away with this anchoring system because they can't use it at all.

Imagine a situation where you want to make a "responsive" grid (4x4) Windows 8 metro style that fills the screen.

Now you have to anchor to the camera using the "custom" option and filling 0-0.25,0.25-0.5,...

It's a pain in the ass doing that and when you want to change it to 5x5 for example...

And also the pivot option that I implemented myself but I want to be in NGUI core.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: makeshiftwings on February 06, 2014, 01:51:33 PM
A few things that would make my life much easier:

1) When selecting "Unified" anchor, put checkboxes next to Left, Right, Top, Bottom to turn them on or off.  I know you can do it by using Advanced and deleting the object from the fields for the ones you don't want, but that's unintuitive and takes up a lot more inspector space.

2) There should be a way to set a fixed width in scene mode for designing your UI, and not have it automatically move around when you resize the play mode window.  Nothing else in my scene view while in scene mode reacts to me moving or scaling the play mode window, so it's disruptive to have NGUI do it.  Especially since I usually have the play window under the scene window, and enlarging the scene window so that I can have a better view of my GUI has the exact opposite effect because it causes everything to fly off to the sides of the screen in whatever ridiculous aspect ratio the play window is in.

3) We should be able to set the size of a non-clipping panel.  Currently to make something like a window I have to make both a panel and a blank widget and set the size in the widget.  This seems dumb since a panel has its own rect already and just adds more clutter to the hierarchy.  I think for most people, the use case of a panel with some sort of size to it comes up much more than a use case where you need a panel of infinite size.  I guess a simpler way would just be to make a panel a widget.  Is there a reason that a panel is not a widget?  Maybe you could add a "Window" or "Container" class that is basically just a panel-widget, if you need to preserve backwards compatibility for people who need infinite size panels?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: KyleStaves on February 06, 2014, 05:03:03 PM
I agree with makeshiftwings on his #1 pretty heavily. I make a lot of use of strings that I want to ResizeHeight and anchor to another widget or panel, it feels pretty common and time consuming to set that up and then the anchor inspector looks very cluttered all the time.

I also think it would be super cool if you started to move towards making NGUI more extension friendly overall. I find myself writing more and more reusable extension scripts and NGUI is one of the more time consuming things I do this for. Even simple things like a property drawer for atlas/sprite selection would be an incredibly cool time saver.

  1. [UIAtlasDrawer][SerializeField] UIAtlas mAtlas;
  2. [UISpriteDrawer][SerializeField] string mSpriteName;
  3.  
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Litherad on February 07, 2014, 03:01:05 AM
The ability for a sliced sprite to wrap around content widgets, for example a textbox or even a collection of widgets of variable sizes (wrapping around their collective bounding box).
Unless the functionality is there and I just can't seem to find it :P
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: lzt120 on February 11, 2014, 04:28:01 AM
I wonder if the Data Binding  is in schedule ?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: LaeusPF on February 11, 2014, 12:29:34 PM
First off, just wanted to thank you for NGUI. I've been an evangelist for the product for over a year now (my latest shipped game, Echo Prime for iOS and Steam, uses NGUI quite extensively).

Since you asked what makes us rage out, I have to confess that the new right-click intercepting for the context menu drives me absolutely bonkers!! In fact, I moved it to ctrl-right-click in my NGUI source. I always navigate the editor using rclick-hold and WASD, and IMO, a plugin should not take such fundamental editor controls away :). Unfortunately, I'm still seeing a performance drop when I have any NGUI object selected and am trying to navigate, so my patch isn't complete. I would love it if this became an NGUI editor option for those who don't mind the disruption.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: makeshiftwings on February 11, 2014, 06:12:50 PM
A few more headaches with the new anchor system:

- As mentioned above, it should be easier to only anchor to particular sides (top and left) rather than needing to anchor every side.
- To go along with that, if you use Advanced mode and leave some anchors blank, you need to re-enable the widget size controls so we can actually size it.
- Ideally, don't ever disable the widget size controls, and just change the anchors if the user changes the size (maintain anchor based on pivot location) and vice versa.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Hawkins on February 11, 2014, 08:00:12 PM
@ArenMook then no chances of CVS support, in the Language component, appear in an update of NGUI? I think I'll have to buy a plugin in AssetStore only for this functionality  :'(

A few pages ago, I gave a feedback on the translation system (post #120 (http://www.tasharen.com/forum/index.php?topic=6615.msg33352#msg33352)), but I think it has no importance.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on February 11, 2014, 08:55:16 PM
@Hawkins: CVS is a versioning system. I assume you meant CSV, comma separated value file. Yes, it's certainly on the list, and your suggestion was excellent.

@LaeusPF: You could also technically just hit escape to clear the selection from the widget then you can move around freely. RMB being disabled was in part intentional because panning around the UI is rarely something desired. Game objects, certainly... but UI, not so much.

@lzt120: It's actually been there since December (http://www.tasharen.com/ngui/docs/_property_binding_8cs.html), but I haven't finished it as I hesitate to release something without actually using it myself. That's why you don't see it in the standard version.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Tripwire on February 12, 2014, 04:33:36 AM
Would it be possible to add the Play Sound script in the attach menu?

NGUI -> Attach -> Play Sound

Would be nice to not have to search for the script every time :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: lzt120 on February 12, 2014, 05:50:51 AM
If release the data binding for public, you can improve it more quickly by response from community.As the saying all are saying it  is good it is actually good.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: LaeusPF on February 12, 2014, 04:40:37 PM
@LaeusPF: You could also technically just hit escape to clear the selection from the widget then you can move around freely. RMB being disabled was in part intentional because panning around the UI is rarely something desired. Game objects, certainly... but UI, not so much.

Thanks for the quick response, though I must respectfully disagree. :)

It seems to me that navigating a Unity scene is a core flow that should always be predictable, whether I want to examine a generic GameObject or pan across some UIWidgets. Specifically with regard to UI, I often need to get much closer to some UI elements so I can align or scale them precisely, but this is now broken in NGUI. Or I might have some 3D UI elements in the scene and I want to examine the scene's contents without losing my current UI selection. Having to unselect and re-select widgets every time I want to navigate the editor using baseline Unity controls is not a good suggestion.

I could definitely see intercepting right-click if NGUI had a separate "layout editor" or something similar, where it's understood by the user that they're in a special mode.

If this must remain in place, perhaps you could make right-click work like it does in modern OSes where it only traps it if you don't start panning around? i.e., if I right-click and release without moving, it pops up the context menu; if I right-click and hold, it preserves Unity's fundamental control paradigm?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Hawkins on February 12, 2014, 08:39:56 PM
@Hawkins: CVS is a versioning system. I assume you meant CSV, comma separated value file. Yes, it's certainly on the list, and your suggestion was excellent.

Is CSV, yes, I apologize for the typo. Well, this is a feature that I expect much in NGUI, almost bought a plugin or moved to another GUI system only because of the support CSV, but like you said it's on the list, I'll wait. Thank you, I can only thank you for keeping this wonderful plugin that is NGUI.

-------------------
Another suggestion is to be able to attach the size of a sprite to the parent widget. So whenever a Widget or Panel is resized, the size of the sprite inside it will increase or decrease in size. I find it very useful to anyone who creates Menu or HUD using a sprite as background, and have to be changing the size of the Widget/Panel and then the size of the sprite.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on February 13, 2014, 12:01:44 AM
@Hawkins: If you anchor the widget to another, it will do just that -- resizing the target widget will also resize the anchored widget. That's how the new layout system works.

@LaeusPF: I can certainly make it an option. The threshold approach likely won't work as the event can be either captured or not at the very beginning, but I'll see what I can do.

@Tripwire: Right-click, Attach, Play Sound Script. ;) -- I will add it to the NGUI menu as well though.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Yukichu on February 13, 2014, 04:14:45 PM
After much thinking, here is a consideration:

When I first bought nGUI, I wrote some detailed post on how I couldn't believe the UIInput did not have a blinking caret, the ability to copy/paste, or even move the caret around, and probably some other text-editor type things.  I was pretty much told there was no reason to add this since someone else had already created it (Ultimate Input for NGUI), and basically NGUI was not a text editor, etc.  So I eventually ponied up and bought Ultimate Input around when NGUI 3.0 transitioned.  Ultimate Input was broken for some time in 3.0, and then... lo and behold... all these features I was told would never be added, were indeed added.  So I wasted some money, kind of a bummer (no I could not get a refund, even while it was broken), but the real lesson I learned was...

... there is no reason to not add something to NGUI just because someone else has already done it.

- Infinite Pick Lists.  Add it.  Yes I could code my own, but have a basic version for people to use.  Don't need to make them all fancy and whatnot like the asset store version, so they'd still be viable for some/many cases, but the basics would probably be nice.
-
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Noi14 on February 14, 2014, 04:25:57 AM
More youtube tutorial with table and grid.
It's really hard to start using ngui and to understand how it works with examples.
I think video step-by-step are better.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: hrlarsen on February 15, 2014, 12:52:47 PM
Hi

I would love to see a feature for sliced sprites where one can also hide the cornors. If you change the sprite type to advanced you have 5 options (left, right, top, bottom, center) however I think that the cornors are missing from this (something like: bottom right, bottom left, top right, top left). With this method you could cut a sliced sprite in half or remove one side, because as it is now, you can't. You can cut in half using the filled sprite type, but then you loose the sliced abilities. :(

Hope to see this soon if possible

Best
/ Jacob
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: amaranth on February 15, 2014, 05:00:45 PM
Two more requests:

Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on February 16, 2014, 02:04:32 AM
Re: Raycasting -- check the version notes for 3.5.0, amaranth.

Unity 4.3 added the 2D features, but the scripting side was incomplete. Unity 4.5... or is it 4.6 now? is what adds the missing script functionality, so you will be able to use 2D stuff with NGUI, resulting in automatic atlas creation should you choose to use 2D sprites.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: wangzy_88 on February 20, 2014, 10:12:57 PM
I'm very happy about the improve of scrollView in new version,will try.
And,do you have any plan with data binding?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Ivian on February 21, 2014, 03:48:52 AM
I'd love to see hierarchy based sort mode.

ex hierarchy

-Root
--Sprite0  1
---Label0  5
--Sprite1  3
---Label1 2

So now, all of these widgets have their own global depth. I'd like to see the featrue, that depth is parent based.  So render queue looks like:
Sprite0, Label1,  Sprite1, Label0. If the depth was hierarchy based First of all we'd render all children of sprite 0 (regarding to their depth) and then all children of Sprite1. So the render queue would look like this: (Sprite0, Label0), (Label1, Sprite1). That would be helpful to create separate windows that could overlap each other, without depth glitches.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Yukichu on February 21, 2014, 10:37:40 AM
Can't we set depth on the panel now?  Seems to completely take care of this for me.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Cynikal on February 22, 2014, 01:21:58 PM
Personally, I think more out of the box type of things would be great.

Example: More atlases consisting of buttons, etc.
More Widgets types: Speedometer, HTML browser?, etc.

Mainly, more premade atlases with the art assets in it, for buttons and stuff.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: 10FingerArmy on February 23, 2014, 04:14:10 PM
It would be great if there were more text effect options. The currently existing outline, gradient and shadow are a superb start but how about:

* outline AND shadow (with different colors each) in one text
* bevels
* materials for font and outline

Something that could be an inspiration here is the following thread: http://forum.unity3d.com/threads/227790-TextMesh-Pro!-Advanced-%28SDF%29-Text-Rendering-amp-Editor-Tool-Looking-for-Feedback
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Nicki on February 23, 2014, 05:23:00 PM
Oh wow, that TextMesh pro thing you linked looks pretty sweet, 10FingerArmy. I'd be all for getting all that into NGUI if at all possible.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: TommyT31 on February 23, 2014, 09:50:25 PM
There are a couple things that drive me absolutely nuts about using NGUI.

1. It seems like I can't select a bunch of widgets in the inspector then just move them with out all hell breaking loose and all of them collapsing on one of the widgets. I have ended up getting around this before by throwing a temp game object in there and putting all my labels or whatever on them and moving the object but this just seems kinda crazy to have to do this.

2. Another thing is duplicating objects. For some reason when I duplicate objects the position and scale always get messed up. Its always slightly less then the previous object. I don't seem to notice this duplicating non NGUI objects. I know that now we use the widgets size but the position is still always off by .0001 or something and my OCD kicks in and I must fix it and the scale..

3. Im not sure why but it seems like when I use it I always feel like I'm fighting it every step of the way to get it to do my bidding. The widget sizes being off on duplication, not being able to multi-select and move, going to move an object and it wants to rotate it when the move cursor icon is up and not rotate.I seem to run into a ton of these nuances. Ive learned to accept these quirks and move on but these things cause extra time required and not to mention keep me pulling my hair out.

I have to say that before making the jump to do my conversion to 3.x I took a real hard look at DF-GUI and I was pretty impressed. It seems to lacking in the overall power aspect that NGUI has but the way it works in terms of creating and laying out widgets just feels more natural to me. The inspector fields are laid out more like I'm using visual studio on a pc to create a windows app. It didn't seem to have as steep of a learning curve as NGUI either.. Granted the learning curve has come along way and thanks for the videos you have done.. Perhaps some more basic videos would be nice..
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Ivian on February 24, 2014, 06:23:24 AM
Can't we set depth on the panel now?  Seems to completely take care of this for me.

Not really. Cuz when i put a sprite on uiPanel object for easier moving the object around, I'm loosing control on the size + anchors to parent. In fact, every widget could now behave as a panel.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Yukichu on February 24, 2014, 10:21:20 AM
2. Another thing is duplicating objects. For some reason when I duplicate objects the position and scale always get messed up. Its always slightly less then the previous object. I don't seem to notice this duplicating non NGUI objects. I know that now we use the widgets size but the position is still always off by .0001 or something and my OCD kicks in and I must fix it and the scale..

I used to think this was NGUI when in fact it is Unity.  I just happen to duplicate a lot of UI objects and not a lot of others, so it seems more noticeable for UI stuff.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: helmesjo on February 25, 2014, 09:27:24 AM
Finish the layout-system!

I watched the new layout-system in one of the videos and it looked promising (anchors), but trying it out myself I noticed (if I haven't missed) that it is extremely lacking. Basically there is still no way to create basic constraints, eg. making one widget keep same height as another widget (unrelated of where they are positioned that is, which won't work with current anchor-system).

Just started using 3.x so I hope I'm not "ranting" without enough knowledge here, but you should really look in to making a complete, from the ground up, layout-system (recently been doing a lot of iOS-development, so that is somewhat what I'm thinking of). The current anchor-solution looks hardcoded (4 anchorPoints built into the widget-component) and really limited and only solves one specific case of all the positioning/scaling/rotating/whatever-issues there is with UI-layout. Because of this widgets should be able to have multiple constraints: Equal width/height, distance from edge to edge (like the anchors do), equal ratio (?), etc. I fail to see how the current system can be extended to support this behaviour...

Look here to get an idea of what I'm blabbing about: https://developer.apple.com/library/ios/documentation/userexperience/conceptual/AutolayoutPG/AutoLayoutConcepts/AutoLayoutConcepts.html#//apple_ref/doc/uid/TP40010853-CH14-SW1

Cherio!
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jtfrench on February 25, 2014, 12:10:20 PM
All I want for NGUI is a definitive programming guide. The NGUI "Bible" of sorts. The definitive place where all forum hooplah can be resolved with a simple answer like "Read Chapter 10: Constructing Multi-Resolution UIs".

That would make my day.

I voiced this here: http://www.tasharen.com/forum/index.php?topic=7463.msg39076#msg39076
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on February 25, 2014, 03:07:42 PM
@helmesjo: Switch the anchor type to advanced, and you can specify 4 individual anchors, which can be set or not, and which can even point to different objects altogether. If you wanted some widget's height to be adjusted by another, then do just that -- set top and bottom anchors, and don't touch left and right.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: helmesjo on February 26, 2014, 02:02:50 AM
I'm sure it can be solved in that way, but it's no solid solution IMO. Because of each anchor being relative to the object in worldspace from object to object (A's distance to B), if A is somewhere else in the scene (not even at the same height), the "A-bottom to B-Top"-anchor will be some arbitrary number I'll have to manually calculate depending on how far they are away from each other, right? For more than extremely simple UI's, this will not work (lets say I later on move B without changing it's height, A will still change height).

Right? This is because of the anchors always working with the rects edges (instead of also allowing to only manipulate the height for example). If you look at my link you see that constraints can be set to specific attributes (width, height, CenterX, CenterY etc.). That allows for one "widget" A to both stay centered in X to B, while at the same time keep same hight as B (since CenterX is not a combination of two anchors hooking from A's top & bottom to B's center with some hardcoded distance).

Trying to keep it short so sorry if it's hard to understand my vague examples! (:
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: adam718 on February 26, 2014, 05:01:18 AM
Hi.
I want Popup list to be improved like in PC and in Mobile. (scrollable when many items)
When i add 10 or 20 items to popup list, it doesn't scroll in certain area.
Popup list stretches to the last item so that i can't select the item which is out of the screen.

I love NGUI.
Thank you.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jingato on February 26, 2014, 11:40:35 AM
I would like to be able to add gradients to sprites. It would also be cool to have either liner or radial gradients.

I'd also really like to be able to hold shift and have widgets scale uniformly when using the handles. Also be able to hold shift when dragging a sprite to constrain the movement to a sigle axis.....similarly to photoshop
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Anomalous Underdog on February 27, 2014, 11:57:34 AM
I'll add my vote to having percentages for the new anchor system. It's one of the reasons I'm still using the old UIAnchor and UIStretch.

Also that "keep ratio" thing that UIStretch does. To make an analogy, it's like in a typical image browser. You can:

1. auto-fit the image's width to the window (which may cut off top & bottom parts of the image)
2. auto-fit the image's height to the window (which may cut off left & right parts of the image)
3. auto-fit the image's width & height to the window, ensuring all of it is shown in the window <-- it's this behaviour that I can't seem to create with the new anchor system, but I can, using UIStretch.

Last reason, UIAnchor and UIStretch allows me to anchor and/or stretch multiple sprites at once.

For example, a row of buttons, I parent them all to an empty game object. That empty has a UITable or UIGrid so all the buttons inside it are arranged nicely, then I use UIAnchor to snap them all to the right edge of the screen.

Perhaps if we had a new class that can contain sprites inside it? It would be just like a sprite; it has width and height, it uses the new anchor system, but it doesn't render anything. It would only be for layouting. "UIContainer" perhaps? Right now, I do this by having a sprite whose alpha is set to 0, but that's rather awkward.

Also it seems UIButtonOffset doesn't take into account when the screen/window size changes. When the screen size changes, it still tries to tween to the old position.

Also minor suggestion: in the new anchor system, when using advanced, how about a button to clear a sprite's anchor per direction? right now when I want to clear it, I have to click on the circle so the selection window comes up, scroll all the way to the top so I can choose "None".


EDIT: btw, please tell me if any of what I describe is not the recommended way of doing things.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: arkon3 on February 28, 2014, 08:34:54 PM
For me the biggest problem or need is the new event system. I used to be able to hack UIButton etc to make send message send a parameter to the receiver. Can't figure out how to do this with the new event system. I have many times needed to have one receiving function but need to do something based on a parameter.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Ivian on March 04, 2014, 04:39:26 AM
Disable accepting input per panel.

In NGUI 2.x I had for each window a separate camera, so when i was hiding them i could disable UICamera script, and everything was fine. Now i can have only 1 camera, so i have to use UIPanel as a root for window. There would be nice, if there would be a "acceptInput" field for panel. I've already modified some code, so it works, but I'd have to update the code each time NGUI updates.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: hexaust on March 04, 2014, 05:44:40 AM
Any chance of adding rulers and guides support?  :P
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: gyd on March 05, 2014, 02:57:36 AM
Add "Set as Current" button on Tween*s' inspector please

ex:
TweenPosition

from x[0] y[0] z[0] [Set as Current]<====
tp    x[0] y[0] z[0] [Set as Current]<====
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: zazery on March 05, 2014, 03:16:19 AM
Add "Set as Current" button on Tween*s' inspector please

You can already do that, checkout the options in the gear menu on any of the tween scripts. It should probably be mentioned in the documentation. I only learned about it through watching the video tutorials.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: gyd on March 05, 2014, 03:50:38 AM
You can already do that, checkout the options in the gear menu on any of the tween scripts. It should probably be mentioned in the documentation. I only learned about it through watching the video tutorials.

oh my god, thanks!

additional:
i think if there are arrow (or other button type) button on the Inspector, will be more easy to use.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Jofator on March 07, 2014, 03:21:43 AM
First thanks for great NGUI.

Maintaining localization in projects is pain.
NGUI helps, CSV support helps, but still localize out of context is hard to do.
And this is where NGUI helps with its localized preview.

It would be really GREAT not only preview BUT MODIFY previewed text for any language!

Best regards!
Jofator
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: helmesjo on March 10, 2014, 02:31:58 AM
NESTED PANELS WITH CLIPPING

I apologise if this is a repeating question, but I did some searching (also checked FAQ) and all I can find is you telling people "this isn't possible". Now, is it _really_ not possible, or is it to much trouble? Because this is by no means an "advanced"/"OP" feature, and should definitely be present. I don't wanna bust your legs, but paying a big chunk of money for a GUI-plugin and not being able to nest for example scrollviews in a logical manner is really crippling... I'm aware that most of the times it can be somehow solved using different approaches (fake-clip by blocking with extra sprites), but this takes increasing effort and limits the design of the UI.

If it's a limitation in Unity, I'm sure you have some great peeps to convince that this is necessary. :)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Nicki on March 10, 2014, 10:01:07 AM
@helmesjo: It's certainly possible, but it's performance heavy to do. I've done a double scroll previously where a vertical scroll contained sub-horizontal scrolls, but it requires that you keep track of each clip area which is not entirely without troubles. There's no easy way to make this built in.

Essentially, you need a scrollview controller that keeps track of all the sub scrollviews and adjusts the rects. Pretty custom stuff, I'd say.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Dover8 on March 11, 2014, 10:16:43 AM
May I make the suggestion that the FitInternalKeepingRatio option of UIStretch also takes into account the realativeSize variable? I've done this in my version and use it a lot to make pop up boxes fit say 80% of the width of the screen on whichever device they're on. As relative size is set to (1, 1) by default this change doesn't effect the widgets until the relative size variable is changed.

  1.                         else if (style == Style.FitInternalKeepingRatio)
  2.                         {
  3.                                 // Contributed by Dylan Ryan
  4.                                 float screenRatio = rectWidth / rectHeight;
  5.                                 float imageRatio = initialSize.x / initialSize.y;
  6.  
  7.                                 if (imageRatio > screenRatio)
  8.                                 {
  9.                                         // Fit horizontally
  10.                                         float scale = rectWidth / initialSize.x;
  11.                                         size.x = rectWidth * relativeSize.x;                            //added * relativeSize.x
  12.                                         size.y = initialSize.y * scale * relativeSize.y;                //added * relativeSize.y
  13.                                 }
  14.                                 else
  15.                                 {
  16.                                         // Fit vertically
  17.                                         float scale = rectHeight / initialSize.y;
  18.                                         size.x = initialSize.x * scale * relativeSize.x;                //added * relativeSize.x
  19.                                         size.y = rectHeight * relativeSize.y;                           //added * relativeSize.y
  20.                                 }
  21.                         }
  22.  
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: blitzer on March 11, 2014, 01:44:12 PM
I would love to see embedded font size, embedded line spacing, embedded text alignment, and embedded font style.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on March 11, 2014, 05:58:04 PM
UIStretch is a deprecated component, Dover8. The new layout system replaces its functionality, and all widgets have an aspect ratio you can set.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: helmesjo on March 12, 2014, 02:03:03 AM
UIStretch is a deprecated component, Dover8. The new layout system replaces its functionality, and all widgets have an aspect ratio you can set.

I must be missing something here, but how can the new layout system replace UIStretch, when it doesn't support basic equal size functionality? Just to clarify, I'm talking about pure "Equal size", independent of distance from edge to edge... With the new layout system, all I'm able to do is set that "A:s top edge is 10px away from B:s top edge" right? And if I translate A away all hell break lose correct? In my case where I just need a panel to be equal size to the camera, UIStretch works great...
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: hlx on March 12, 2014, 02:30:15 PM
I would greatly like multi monitor support. Right now the anchor system really only works for one monitor.  It would also be great to have moveable "dockable" GUI zones for customizing your in-game GUI interface.

Totally agree with you. I am actually thinking about prototyping a Gui for a Windows application that should emulate an Instructor Operating System for a Simulator project. Dockable components and multi monitor support is really needed in my case. Maybe, there is a native Unity  limitation that doesn t let NGUI doing this easily ?

Hlx
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on March 12, 2014, 04:39:03 PM
UIStretch is a deprecated component, Dover8. The new layout system replaces its functionality, and all widgets have an aspect ratio you can set.

It's NOT the same:

- With UIStretch you can stretch both sides BUT you can MOVE freely your sprite.

- With the new anchor system it forces the position and you can't move it (try unified with left 0, right 0, top 0, bottom 0 to panel or uiroot).
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on March 13, 2014, 12:23:02 AM
It's NOT the same:

- With UIStretch you can stretch both sides BUT you can MOVE freely your sprite.

- With the new anchor system it forces the position and you can't move it (try unified with left 0, right 0, top 0, bottom 0 to panel or uiroot).
You can move an anchored widget quite easily:
  1. NGUIMath.MoveWidget(widgetOrPanel, X, Y);
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on March 13, 2014, 12:36:21 AM
You can move an anchored widget quite easily:
  1. NGUIMath.MoveWidget(widgetOrPanel, X, Y);

Where was that? I didn't know that!

And if you have a "window" grouped and you want to move it not being a widget or panel? or it has to be always a widget or a panel?
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on March 13, 2014, 12:50:19 AM
A plain window game object wouldn't be anchorable using the new layout system as it's not a widget or a panel, so the question becomes moot, as you then simply adjust the transform's localPosition.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: helmesjo on March 13, 2014, 02:47:22 AM
You can move an anchored widget quite easily:
  1. NGUIMath.MoveWidget(widgetOrPanel, X, Y);

I'm sorry but that's more of a hack than a pure solution... If you insist on keeping the current layout-system I would much appreciate it that you didn't deprecate UIStretch. I'm sure it's more used than you think.
I can't stretch it enough (no pun intended!) that you should really look into a constraint-system and do it the right way. Actually, I did put one together myself for our own needs, and it's as easy as just extracting one value from another object and apply it to some value on the other object (basically a pair of switch-cases). The hard part is the solver, which is a big subject on its own but totally doable within a reasonable timeframe (I can imagine). We had a tight deadline so I settled with callbacks & brute force which is of course limited but works. I promise you, once you've tried it out you'll understand the incredible easy of use.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on March 13, 2014, 06:09:24 AM
I think the data binding system I'm adding here will help here. You can just say "this property will now always update this other object's property".

So if you wanted one widget's width to update the other widget's width, you can do just that.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: gyd on March 13, 2014, 06:48:46 AM
For supporting the HOTKEY system by NGUI,
Could the OnKey support all keys' events? (and modifiers of key)
or add a new callback OnKeyDown/Up ?

i know i could do that in Update() myself, but if i do so, there will be 2 Key checking code in my system, thx.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: N3uRo on March 13, 2014, 02:38:57 PM
A plain window game object wouldn't be anchorable using the new layout system as it's not a widget or a panel, so the question becomes moot, as you then simply adjust the transform's localPosition.

I know that but I was speaking of moving all the hierarchy (with possible anchored widgets) beneath relatively.

The main problem I see with the new anchoring system is that you mix positioning and dimensioning... Sometimes I only want to scale an object not force it's position to the anchored widgets. That's why I mentioned the UIStretch case, with that you can fill the entire screen and move localPosition where you want not being forced by any anchors...
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on March 14, 2014, 11:46:46 AM
@gyd: UIKeyBinding.

@N3uRo: Again, data binding / value binding / whachawannacallit system I'm working on will be able to do just that.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: TommyT31 on March 17, 2014, 05:13:14 PM
A great feature that I think would be nice I just realized that would be to have an optional button text color when the button is disabled. I have disabled sprites for my buttons but now I manually change the text color to grey  then back to white when its reenabled. Being able to have this as a option on the buttons would be sweet.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: hrlarsen on March 20, 2014, 11:40:57 AM
I would love to see a smooth Reposition for UITable, like UIGrid already have.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: cjke.7777 on April 13, 2014, 07:40:27 AM
Great work on NGUI. I purchased it probably more than a yeah ago and never really got stuck in to it, but having picked it up again, I'm loving it.

I know you've mentioned improvements to UIGrid is coming, but I just want to voice my opinion - improvements on UIGrid would be great. Especially adding an anchor to it would be good.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on April 14, 2014, 02:50:51 AM
See here:
http://www.tasharen.com/forum/index.php?topic=9028.msg42778#msg42778
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: jingato on May 09, 2014, 04:08:15 PM
It would be great if we could skew sprites so we could make a UI that looks as if it's in a perspective camera without the headache of actually using a perspective 3D UI.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: tvhnet on July 07, 2015, 10:56:28 PM
Please consider feature "anchor size":

width of UIWidget A = ratio * (width of UIWidget B)

height of UIWidget A = ratio * (height of UIWidget B)
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on July 08, 2015, 06:44:38 PM
You can already do this using UIStretch.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: Redd on December 17, 2015, 06:38:36 PM
I would like to see UIToggle be able to support more than one or multiple State Transition. i.e. tween a label color as well as tween a highlight scale at the same time. Thank you for considering my request.
Title: Re: (!!!) Improving NGUI: Voice your opinion
Post by: ArenMook on December 17, 2015, 10:50:49 PM
It actually already works like that if the tween you specified is in a group. At least that's how it is in the current Pro version (3.9.6).

If the chosen tween is in a group, it will get all sub-tweens with the same group and play them as well.