My understanding is that there are currently 3 UI systems integrated in to Cocos; Menu/Items, CCControl (extensions/GUI), and CocosGUI (cocos/ui). I would like to see them better integrated, or a clear sign that 2 of the 3 are being deprecated, so that we as developers trying to help with bettering Cocos can focus on just one, which I would guess would be CocosGUI.
As a C++ programmer coming from iOS, my familiarity/preference has been for CCControl, but I could learn to use CocosGUI if that is the course of action. My issue with CocosGUI is that there is an added layer of abstraction through ProtectedNode and Widget and Layout that can get confusing, and as a programmer I prefer to add the buttons/sliders/scrollviews directly to a scene’s base Layer or sub Layer. As a side note, I think there is redundancy in other places too, like I think that Node, Layer, LayerColor, etc. should all be joined into one class, a Layer with a background layer that is always on the bottom of the child stack.
As others have done, I too have created a system using JSON to do automatic layout, but that was before CocoStudio, which (as a Mac user) is still not “ready for primetime” so it’s not a viable option for me yet. That being said, I would rather see the output from CocoStudio better documented, so we can tweak it directly, than see an HTML/CSS UI system added on top of the C++ version of Cocos. That said, I think Cocos does need a web view class similar to the experimental video player, so we could have an in-app browser for things like privacy policies that live on a website.
I’m very happy that CocoStudio has skeletal armature animation tool, and I am desperately waiting for the Mac version to include it. Spine becomes very expensive once you cross a certain threshold, plus requires some hackery to support 3+ resolutions (at least last I looked). As for other “for pay” libraries, the main reasons I switch to Cocos from Corona for cross platform development is no licensing fee and the open source nature of the product, and having to start paying for closed source libs would become a burden.
google translate does a really good job. The translation is pretty understandable:
Allow me to use Chinese to express:
relatively unusual coordinate system, the origin of the coordinate system is generally in the upper left corner of the UI system, it’s not just given, it has its reason. From left to right from top to bottom of the human eye to see. Not all controls are placed in the UI editor is sometimes necessary code to create, calculate the position, such as ListView, ScrollView, etc., this time you will find that if the origin in the upper left corner, then the calculated coordinates x direction and y direction is the same, but the origin in the lower left corner, then the calculation is different cause, sometimes quite awkward.
2 engine and studio in the current definition of origin is inconsistent, engines Node origin in the lower left corner, but the studio where the origin was in the anchor position, quite accustomed to.
Can refer flash UI framework, quite beautiful and easy to use. . . If cocos can parse swf, that ui editor are saved. . Can refer scaleform
We keep both cocos2d Node and UI’s coordination to be the same mainly for consistency. So that
developers don’t need to switch their thought when positioning UI elements and Node elements.
And in V3.x, we also allow Node and UI elements to be added as a child into each other.
The origin issue has also been fixed since cocos2d-x v3.x. Now they are all start from left bottom corner.
but I prefer the way that CocosStudio use, is their any way to change the way in the UI framework. 我比较喜欢编辑器(CocosStudio)使用的方式(原点跟着锚点走)，有没有办法修改UI framework， 使它和编辑器一致 ^ ^ 。
现在UI framework使用的机制真的好难理解，一个Node, 在它自身局部坐标系内，原点在左下角，和锚点没关系。但这个Node在父容器里的坐标确和锚点有关。我不知道这么说能不能理解，我举个例子吧，假设一张图，我放在屏幕左下角（坐标（0，0），同样的坐标( 都是(0,0)点),锚点不同，你看到的是不一样的，锚点在左下，你就能完整看到这张图，如果锚点在中心，你只能看到右上四分之一的图，锚点若在右上，那么你什么都看不到。 按理说，你们想改成Node怎么显示和锚点没有关系，但是你们这点没有做到。所以个人感觉很难理解。
What about simple json layouts, with some scripting features. For example we dont need to write tons of code to rotate an icon on the button, right? Those things can be easily scripted with lua.
Also the main feature for UI-heavy games is ability to write own gui elements. For example i want a “green button” that is used in every dialog of my game, to be a separate standalone element, with ability to set its title and callback. It can be easily done with code, but i want my json layouts to support it. So we need some kind of custom readers.
Another great feature of using layouts + scripts would be the ability to edit dialogs without even restarting the game. I can go to my resources folder inside simulator, edit files directly there, then just restart the dialog inside my game, and see all changes immediately. After im happy with my dialog, i will just copy those layouts to my resources folder.
I am currently developing very UI-heavy game, and those are the features i would be happy to see.
@pavels
Thanks for your suggestions.
It is more like a data-driven way to create UI and UI Layouts.
I think maybe Json and XML are more general ways than Lua.
