Cocos2d::ui duplications, confusion, missing docs

Cocos2d::ui duplications, confusion, missing docs
0

@slackmoehrle
It seems that there is a lot of duplication between UI elements and cocos base elements.

Some examples:

  1. MenuItem or UIButton?
  2. UIText/UITextBMFont or Label?
  3. UIScrollView or CCScrollView?
  4. UIListView or CCTableView?
  5. UIImageView or Sprite?

First, can we have a detailed answer when to use cocos base elements and when ui staff when there is duplication? I can create a UIListView and add inside non-ui elements like Sprites and MenuItems so why there is separation between nodes and widgets? I must be missing something.

Also, inside the ui folder, there are many classes which are undocumented in the widgets area of the documentation and without examples but look pretty useful like UILayout, UIPageView, UITabControl etc. Can we give some love to ui in docs? :slight_smile: There is so much functionality hidden here and many don’t know.

Yes, but it isn’t your fault. the UI* are from Cocos Studio. This has been deprecated for many years but these classes are still available for use. We didn’t remove them and I don’t think we will at this point.

We should, yes and it has been on a long standing list that I keep of docs to write.

Ok so if they are deprecated, it means we should use the CC equivalent whenever possible.

Many projects rely on them and basic cocos classes do not offer functionality for many of them e.g. sliders, tap bars etc. But i guess the non-duplicate ones should be updated as CC and the duplicated ones removed.

Well, not really. We EOL’d Cocos Studio, but these classes are still alive and well and maintained, etc. I’d feel comfortable using them. They are not going away. They do offer functionality that users need, but are not part of the base classes.

Also, Cocos Studio allowed exporting of Scenes to code. This is why these classes need to exist in the engine too. If an artist exported a Scene to code for a developer and those classes didn’t exist there would be compiler errors.

i.e always use a Sprite when a Sprite is the right class to use. UIImage could handle it, but UIImage has other purposes you wouldn’t use when just using it as a Sprite. Perhaps we can add to the docs something that says when to use what. Maybe in the Other Nodes section.

Use a MenuButton when you are using a Menu and need Menu like functionality. Use UIButton for those one off buttons. You could even use Sprite as a button but you do lose functionality.

I see lots of projects mix and match CC and UI. Perhaps someone will chime in and say why they chose to do that.

“Perhaps we can add to the docs something that says when to use what.”-> yes please. ) Also i think Sonar Systems made a lot of Youtube videos about ui, you can refer to those too. But in docs, its really convienient when you see a quick gif animation and you get immediately and understanding of what a class does without having to leave the docs.

The problem with duplicate functionality is that if we want to add custom funtionality to cocos classes (extend them etc) or e.g. add a custom variable we need to extend both UIButton and MenuItem. Except if a UIButton uses MenuItem underneath or a UIText a Label.

At this moment, i am use UIListView based on UIScrollView but i had no idea if i should have used CCTableView and CCScrollView instead. :slight_smile:

I tell people to use the classes they feel comfortable using. It could be possible that the CC classes give you everything you need. Or, possibly the UI* may have additional functionality. Or maybe the UI* have a more straightforward API. I don’t use UI* often, although I seem to useUIScrollView`. I’m not sure why I chose it.

As I am sure you know, cpp-tests can show you examples of many of these so you don’t have to write the code yourself to test what class is better for your needs.

As far as the documentation, I think we need this to avoid confusion. The engine is large and already a bit overwhelming for beginners. If we can help avoid this, we should. It helps our users and helps remind us what classes do what and why they were designed that way.