What UI system we need?

What UI system we need?
0.0 0


Hi all,

The UI system was developed by Studio team, and cocos2d-x team takes charge of it these days. We have been improving UI system these days:

  • fixing many bugs
  • deprecated confused API and add more clear API
  • remove duplicate codes

But we know it is not enough. The UI system is not good as expected. So we need your feedback and suggestions on:

  • How you feel the UI system
  • What’s not good
  • What UI system you want to have
  • Is there any good UI system we can learn from
  • And so on

We want to improve the UI system, make it powerful and easy to use. Any feedback and suggestions is appreciated.




I don’t know if you also develop at Cocos Studio, but if so: Please improve this tool! To let someone (game artist, …) create the UI/Scene/… is a great way. To “code” the UI isn’t state of the art anymore.

Additionally I would like to have a swipe recognition integrated.

What I really think is not so good…: If I touch a ui::Button than the callback will be called two! times. One for TouchEventType::BEGAN and one for TouchEventType::ENDED. Maybe I just don’t get it, why. I mean, right now I need to make a condition if the touchEvent == ENDED to be sure that the stuff which comes next is only done once. And this condition is almost in every method I use as callbacks.


My opinion is WYSIWYG UI editors tend to be inconvenient, maybe I’ve never found the right one, Visual Studio can be pretty slick. I like to know where the code to place my Widgets is, not hunting through xml, plist, and json files.


Swip recognition, you mean pattern recognition? Desirable as that is I don’t think cocos2d-x is really oriented for it and would do better to concentrate on visuals than providing algorithms we can, #ahem# easily import as separate code files. It would be great but pattern recognition, IMHO, isn’t in cocos2d-x’s remit.


Looks like you are working alone? While working in a team there are also some game artists who know how something is good designed and placed well, but have no idea about coding. That’s also one of the big advantage of the big engines. Someone can do the visual stuff, someone do the coding stuff. To seperate ui and code is also a main aspect in programming. Aaaannddd… If the UI-Editor is used well than you don’t need to look through the file. Additioanlly there are lots of lots of lots topics in this board which refer to cocos studio. I think that shows that ppl want to use such stuff.

What do you mean with swip recognition? I mean gesture recognition (swipe from left to right, top to bottom, …).


I don’t develop at Cocos Studio. But Cocos Studio will use the UI system too.

Yep, Editor is important, but codes should be good too. Because some developers just use codes as @nuttypros did, and Cocos Studio also uses the codes too.

So what you like is gesture recognition.
Thanks for your feedback.


I’ve built my own GUI on top of cocos2d::Node.

My UI base class is called GWidget, and it inherits Node. Some of my GWidget-derived classes are:
HorizontalLayoutWidget, VerticalLayoutWidget, HorizontalSpacerWidget, VerticalSpacerWidget, ButtonWidget,
ScrollViewWidget etc.

On top of GWidget I’ve built windows and also a window manager that keeps track of window Z order and lets you drag windows around the screen. I also have Panels, which are windows that don’t move. I’ve had the Qt way of doing layout in mind while coding this, since that’s what I’m used to.

For instance, to create a requester window with content and a ok/cancel button pair, I do this (pseudocode):

  • Create a GWindow
  • Create a VerticalLayoutWidget
  • Create a HorizontalLayoutWidget
  • Create a HorizontalSpacer, the OK button, the Cancel button, and add them to the HorizontalLayout - the HorizonalSpacer has its isHorizontallyExpanding flag set, which means that it will push the two buttons to the right end of the HorizontalLayoutWidget.
  • Add my requester content, such as a lineedit, scrollview or anything, to the VerticalLayoutWidget
  • Add the HorizontalLayout, with buttons etc in it, to the VerticalLayoutWidget
  • and finally, do GWindow->setContentWidget(myVerticalLayout)

I look forward to hearing about other approaches.

Edit: I had a look at the Studio UI code, but I don’t think it works as dynamically as my system. If I’m wrong, please correct me. :slight_smile:



I’ve used a lot of traditional desktop widget frameworks, and from my experience Qt’s system works best. Their layout system has the usual vertical/horizontal/grid layouts but more interestingly they have vertical/horizontal spacers that in many ways behave like springs that push away the widgets at either end to fill in the space. Of course, when items are hidden/shown the layout is automatically recomputed.


The main issue I have with the new UI system is that it lacks versatility, and I understand why it is this way…

Cocos has long been inspired from Cocoa, even the name was inspired from there, and hence some APIs are rightfully very close. But, when you look at the basic building blocks of both libraries, they are vastly different.

When in Cocoa you get an API to set the title, image, background image, I believe that should not translate directly to cocos. It would be good to have those convenient APIs, but after implementing setBackgroundNode, setSprite, setSpriteWithSpriteFrameName, setTitleLabel, … etc. I mean, I think the developer should be able to build his control with any Node subclass, because why not? We have things like Scale9Sprite, Sprite, LayerColor, ClippingNode … etc, and they are all awesome, but not easily integrated with the GUI code.

P.S: I wish cocos studio can focus on doing one thing, and do it extremely well. We have spine for skeleton animations, SpriteBuilderX for UI and animation (which has an excellent Mac UI), maybe it can tackle another challenge instead of scattering the energy about.


I think something markup-based like QML is good to copy. I’m writing something similar except in JSON that: binds to cocos2d-x elements, allows arbitrary nesting, supports live-reload, and separates style from layout (it’s more like HTML/CSS: the easiest/fastest things to design in).


Firstly, make CocosStudio open source. Then we are able to know what problems in it.


Thanks for your sharing.

Thanks for your sharing. I am not sure if Qt’s system is more complicated for mobile developing. We have take a look.

Just setTitle, setLabel and other API is just to make it more convenient for developers. You don’t have to worry about the implementation. You don’t have to create Sprite by your self. But your thought is interesting.

Thanks. Would you should some demo?

We are talking about UI system in codes. About Cocos Studio, i don’t have the permission to let it open source. And i am not developing it. Sorry.



  • Revamp and simplify MenuItem classes. Use a single class with
    different create method (factory?). Label class already done
  • Gesture
  • Alignment. We have anchor points. But what I want is that a child node should attach to parent without extra calculation. Say for example, if I want to add a Label to bottom right corner of a Sprite, I should do addChild(child, zorder, tag, Alignment::BOTTOM_RIGHT)


One thing that really bugs me is centering widgets in layout in both directions.
In android development you can set gravity for both axis in layout like this:

widget.setGravity(Gravity.CENTER | Gravity.BOTTOM);

In cocos2d-x it can only be one axis so you have to put layout in layout
to center it vertically and horizontally.


I believe a markup based UI editor is perfect for many use cases and games, but for more organic UI with animations and transitions, it might be very problematic. Did you figure out a solution for that?


Yeah, I agree they are convenient and can be kept for simple UI prototyping, but in my game, I actually had to create Control or Widget subclasses to do things I thought should be relatively straight forward, like having a button with a background image, and then an icon on top of it.


Good suggestions. We will move Menu and MenuItem into UI system and simplify it as you said.

Thanks. We will consider it.

So any suggestions? Did you mean we should add these functions? If so, then what functions you think missed?


Thanks for the replies.

I didn’t have time to actually break down the requirements into the perfect API I would be interested in, but simply taking my use case, I would suggest adding the following:

auto button = ...;
button->setNormalBackgroundNode(/* Any node whatsoever */);
button->setSelectedBackgroundNode(/* Any node whatsoever */);

button->setNormalForegroundNode(/* Any node whatsoever */);
button->setSelectedForegroundNode(/* Any node whatsoever */);

Using the calls above, the developer can “transform” any node into a button. As long as the boundingBox() property is properly calculated on the node you pass, touches/collisions can easily be detected.

Here is the example from my game (Note that the icon image is separate from the background image):

Normal state:

Selected state:

Now that I think about it, this is very close to the decorator pattern. It think architecting a UI framework with the decorator design pattern in mind will prove extremely useful.


Thanks, @Mazyod Your suggestions are helpful and your mention of decorator pattern hints me how we could customize our control’s view presentation.


I personally like the way CSS handles transforms, but in my system, I use cocos’ terms and store them in an array. @zhangxm I’m busy with my other games but I’ll post a demo for you guys when I can. The implementation is basically a big factory that reads properties from JSON (with conveniences where possible like hex-string color notation), maps them to a corresponding cc2dx component/property, and applies it.