What UI system we need?

What UI system we need?
0.0 0

#41

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.


#42

容许我先用中文表达一下:

  1. 坐标系比较反常,一般UI系统的坐标系原点在左上角,这不是随便定的,这是有它的道理的。人眼是从左到右从上到下看的。 不是所有控件都是UI编辑器里摆放的,有时需要代码去创建,计算位置,比如ListView,ScrollView等,这个时候你会发现,如果原点在左上角,那么x方向 和y方向 的坐标计算方式是一致的,但原点在左下角的话,计算方式是不一致的,有时候还相当别扭。
  2. 目前引擎和studio里对原点的定义是不一致的,引擎里Node 的原点在左下角,但studio里的原点却在锚点位置,相当不习惯。

可以参考flash的UI框架,相当漂亮和好用。。。如果cocos可以直接解析swf,那ui编辑器都省了。。可以参考scaleform

谁帮忙翻译成英文吧。。


#44

google translate does a really good job. The translation is pretty understandable:

Allow me to use Chinese to express:

  1. 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

Who help translate it into English. .


#45

Thanks, @shmilypyj

  1. 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.

  2. The origin issue has also been fixed since cocos2d-x v3.x. Now they are all start from left bottom corner.


#46

The origin issue has not been fixed yet. I just download the latetest cocos studio 1.6.0.0.


#47

yeah, it has been fixed in the UI framework, but the editor(CocosStudio) haven’t, sorry for that.


#48

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怎么显示和锚点没有关系,但是你们这点没有做到。所以个人感觉很难理解。

所以还是cocosstudio的方式比较好理解, 或者如果你们真正能做到Node怎么显示和锚点没有关系的话,那我相信也能理解了。

不过真的做到了Node怎么显示跟锚点没关系的话,那也有问题。 就是缩放和旋转的时候,坐标也会跟着变。 总之就是cocosstudio的方式比较好,我记得cocos2dx-3.0 beta2还是cocosstudio方式的,那个时候多好,什么问题都没,现在你们 “fix” 一下,问题多多。

最后再弱弱问句,有没有办法修改一下UI framework回到以前的方式,真的好怀念以前的方式。。。


#49

现在的UI与Sprite等Node结点是一样的,如果您理解了现在的Sprite的布局方式,自然也可以理解UI的布局方式了。

另外,Node的父节点的原点永远是父节点的左下角,而与锚点无关,这个是cocos2d从诞生之日起就存在的方式。

我们fix只是为了统一Node和UI元素,因为现在我们可以往UI里面加Node,也可以往Node里面添加UI。如果不统一,会造成开发者更难理解。


#50

那如果现在的Sprite的布局方式本身就不是很好的方式,然后你们为了保证大多数使用cocos的人的习惯,也不会改是吗?

我可能flash用多了,所以不大习惯现在的Sprite的布局方式,看来得自己改改习惯了。

现在只希望编辑器能尽快同步,说不定能习惯一些了。

非常感谢!!


#51

Please use english.
Or other developers don’a understand what you said.
How will you fell if others say Korean or Russian?


#52

The Studio Team is trying hard to keep synchronization。
Thanks.


#53

Sorry, my english is not very good. Reading has no problem, but writing has lot of problem,especially complex thing.


#54

@shmilypyj
Fell free for writing English.
Forget the grammar. And i think your English is good.


#55

@shmilypyj
Or just use google translate and post that translation, if you are that insecure. Actually it’s quite good.

But anyway. Who cares about the quality of your English, as long as people get what you wanted to say.


#56
  1. 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.
  2. 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.
  3. 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.


#57

@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.


#58

There is also TurboBadger: https://github.com/fruxo/turbobadger


#59

We need the ability to disable the full screen keyboard when entering text into a ui::TextField so that we can see the environment we are typing in


#60

Ability to use Blend (XAML) for UI development in cocos2d-x will be great!


#61

Hi, I am one of the programmers in charge of NoesisGUI.

Just tell us when do you want to start with the integration! :smile: