Integrating aspects of uGUI further down the line?

[Grofit]

So I have tried to find out information on uGUI and nGUI and where there is overlap and what functionality is provided in one which isnt in the other etc. I also read previous posts here where you state the boundries of uGUI and nGUI and that you may further down the line look at incorporating some of uGUI features into nGUI and this is the focus of this question.

So currently from a primitive overview of what nGUI offers (taking support aside and just dealing with technical features), it seems like there is a large overlap in functionality (which I would expect given you did the initial work on uGUI) and you have mentioned before that uGUI can take advantage of certain performance benefits as it is part of unity core and it also has some new features that nGUI does not have.

Now looking at a new project currently I would be tempted to move over to uGUI given that the way you speak about nGUI is that you will maintain and possibly update nGUI 3 until end of the year but you do not sound (At least to me) like you have long term goals for it now. As currently it is basically going to be nGUI or uGUI, which if I were a betting man from all the things you have said so far and the route Unity are taking with it, uGUI will end up coming out on top. So I am just wondering if you have thought about the possible approaches going forward so you can make it less of a uGUI vs nGUI issue and have it so nGUI was just kinda built over uGUI to fill in the gaps and provide some additional features. As I would love to continue using nGUI but I would ideally want to know that given the amount of overlap I could at least make use of some newer features in uGUI if they do not appear in this framework.

I am waffling a bit, but I hope you can see the angle I am coming from, your network lib builds on top of the existing network functionality in unity, however nGUI is currently functionally comparable but technically incompatible with uGUI so I was hoping you could provide some more information on if/how you are going to reduce the incompatabilities and if there is a migration/integration roadmap in your mind as to how you would like to merge the 2 as much as possible to give devs the freedom to capitalize on the benefits of both systems?

[ArenMook]

My plans for NGUI are simple: I'll keep using it, and as such I'll keep adding to it. I'm not saying the support will end at the end of the year, I'm merely saying that I will most certainly be using it until the end of the year, meaning there will be updates coming. After that, depends on what I'll be doing and on how uGUI is received.

I actually had a look at uGUI last week with the idea of making it possible for NGUI to use its functionality. Unfortunately with the amount of recent changes over the last year it wasn't a simple undertaking by any means. The way certain things were done makes meshing them together difficult. The way draw the order is handled being the main one. NGUI gives a lot more control here, and a child sprite can be drawn before its parent if so desired (think: shadow). This isn't possible in uGUI. If there was a way to specify depth on canvas renderers, then everything would merge over smoothly, but the way things are I can migrate a UI from uGUI to NGUI, but the other way around is not so simple.

I will likely add a new widget type soon that will be like an NGUI sprite in terms of its functionality, but will be drawn by a uGUI canvas and then see from there.

[Grofit]

Hey,

Thanks for the response, like you say I guess see how things go.

This all started because I was talking to a friend about gui libraries as he is wanting to look into gui for his project but has not used anything before. I recommended nGUI having used it and not really looked at uGUI (have done since that conversation), and he was saying that there is no point picking up and learning nGUI given that uGUI seems to be superceding it, and its free. I kinda agreed with his points but given that there are some features nGUI has that uGUI doesnt and vice versa I just wanted to know if you were planning on still keeping nGUI competitive or if you are basically looking to retire it or reduce your maintenance by refactoring some of your code to use uGUI so it becomes less work to manage etc.