What UI system we need?

I think the license term of NoesisGUI is not good for Cocos

Check the JUCE Audio engine, it is already cross platform.

But donā€™t forget one thing: it is GPL!

Do I have to pay to use JUCE?
Most JUCE modules are shared under the GNU Public Licence (GPLv2, v3, and the AGPLv3). This means that the code can be freely copied and distributed, and costs nothing to use in other GPL applications. One module (the juce_core module) is permissively licensed under the ISC.

If youā€™d like to release a closed-source application that uses JUCE, commercial licences are available for a fee.

Yeah, maybe we can negotiate with creator of JUCE

Good thing about JUCE that it is already cross platform, and they have really really good sound engine. It already supports like panning, pitching etc out of the box. Even the synthesizer for dynamic sounds generation. Wrapping it in cocos2d-x wouldnā€™t be large effort but the benefit will be really good.

Well, it all depends if you want to introduce a big framework into cocos2d-x.

we need cocos studio for mac

I am glad I have been putting off the time investment of learning DF-GUI or NGUI and working on other things while waiting for this system. I am looking forward to using the new UI system; canā€™t wait!

This is very useful

The UI Systems was great. Nice job
But I want a little bit more, about debugging.
Seem like in each widget has setDebug(bool) to turn it on or off.
Well, when it turned on, the layer ( or scene, etc ) will draw the boundingbox of it ( and may be itā€™s anchor point if possible ), and turn off to default mode ( currently ) This feature may let programmer who doesnā€™t use cocostudio. Iā€™ve seen and used it with LibGDX and hope Cocos2d-x has it too :smile:

These are important features which are very useful:

Strong model/view separation. This is a ideal sequence:

  1. create model data (completely independent on presentation)
  2. create display controls: same model can be displayed in variety of ways
  3. size and layout the display controls: support multiple devices (phone/table) and screen orientations.

Then it is super easy to support variety of devices and themes. Changing the theme might require only changing the method implementing the step 3. and all the other application logic remains the same.

Implementation of these steps:

  1. model representation is nothing else then a data container. It pretty much dependent on programming language. Super easy in JavaScript: {name: "Josef"}.

  2. display controls: This is dependent on cocos library. You can either create native control wrappers or implement your own. Iā€™m not sure you can ā€œimportā€ much of a code here from other frameworks.

  3. layout: this should on the other hand really leverage the experience which is in place. I agree that CSS based/inspired solutions are very good choice. It is widely adopted and it has many good features (e.g. flexible layout support). Plus it has many existing tools on the market. What if we find an easy way to use CSS as is. You would simply pass in array of controls and one CSS stylesheet which would layout the controls in a parent node. With such solution in place you can use any existing tool to create the CSS visually and you are done :wink:

Once I was thinking about trying some of the CSS based rendering on my own.
Here is the topic on stackoverflow: http://stackoverflow.com/questions/27045639/css-interpreter-for-custom-gui-renderer-in-javascript

I appreciate Cocos2Dā€™s UI system, since I want to make games that are relatively UI heavy while there are few open source game engines that have a robust UI system. In my opinion, what the UI system is most lacking right now is automatic sizes and positions for widgets.

For example, I just tried to create a widget with two columns of buttons. So I used an outer Layout with its layout type set to HORIZONTAL and two button-containing Layouts with their layout types set to VERTICAL. Unless I explicitly set the content size of my Layouts - at minimum the first vertical layout - the second vertical Layout overlaps the first vertical Layout.

Thereā€™s also a use case where I may want a widget with two child widgets, where the first widget has a fixed width while the second widget expands to the remaining width of the parent widget.

I havenā€™t checked out the UI for a year.
Were they implement or still in progress? Thanks

Its good to see that your team have taken charge to improve it.So my suggestions are as follows::

  1. It should support Windows Phone also currently it is only supporting win32.As I am developing on that and I am not able to use Cocos Studio because of that.
  2. Studio should have properties like unity has for its UI.

We have posted many fork on this issue but not got any reply from your side.
Hope you will consider it .
All the best.
:smile: