ScrollView为啥不加一个addItem()的接口呢?

我如果给出标准你信吗?我自己都不信,我也不是引擎组的人,所以引擎为什么要按照我的标准来呢,我说的大体分类就是组件名,你可以自己想想为什么这个拆分出来的组件名是这个,当然也可能不对,这只是我个人理解而已,具体规则可以自行询问引擎开发组
而且按照我的逻辑,再极端我也不会创建无用的组件,更不会一个属性一个组件,除非这个组件后续要扩展

这句话我可以简单的举个例,普通人看书是喜欢看一本有目录分门别类规划好内容的书,还是看内容划分不明确各种类型的内容穿插其间的书?

直接把锅甩给官方就对了,单独一个UIOpacity肯定是无奈之举,并不是一个多么高明的不得了的设计,反而是一个糟糕透顶的渣渣措施。与其说是无奈之举,不如说是为了省事。懒得重写很多代码!当初的不谨慎,如今我们使用者为官方以前的不良好设计买单

这些没有标准的争论最后都会变得自说自话,我上面说的很清楚了,一个对象有哪些属性只取决于对象是什么,我上面的说明没有任何一条能推出我赞同“看内容划分不明确各种类型的内容穿插其间”这个情况
面向对象或者基于对象编程大家都懂,争论还是因为确实有很多模糊地带,还有些为了方便维护而做出的设计妥协,所以引擎的发展还是要多分析实际用户的需求和反馈

在你说出这句话的时候我就知道没必要和你讨论了,没有联想能力,没有逻辑思维,道不同不相为谋,你可以继续找和你相同想法的人讨论

这是本人开的提问帖,且主要针对官方提出建议
到目前为止我也没对你进行任何人生攻击,都是就事论事
帖子都是公开的我也没删任何留言,至于谁“没有联想能力,没有逻辑思维”大家自有公论而不是自我评价
我自然也有与我想法相同的人,你也会有与你想法相同的人,我想找谁讨论完全不需要你来建议
开帖子的目的就是针对帖子的问题来公开讨论,这个帖子也并不是针对你开的,自然也有可能有其他与我想法不同的人来此讨论

最后说明一下:

逻辑问题:

这个没有标准的结论请问你是怎么得出来的?是否咨询过引擎组人员?还是说我觉得这样就是这样

联想问题:

  • 组件 = 章节
  • 属性 = 内容

这句话我想作为有经验的程序员根本没资格站在无经验的程序角度说,事实上官方目前就是通过各个组件划分原本node的各个属性,有多少新人吐槽这个问题呢?

我们之间的讨论肯定是我们之间定标准,我又不是再跟官方讨论并质疑他们的标准,官方也没有回复我为啥不加这个接口以及是否加这个接口
如果你是基于“官方肯定有自己的标准,官方这么做肯定有官方的道理”这个猜测为基础来跟我讨论为啥官方不加这个接口,那没有意义,请先证实这个猜测的正确性,但言语间你显然只是猜测并且说自己不知道官方的真实目的
那你在前面的一系列跟我的讨论只能基于你定义的标准或者你的想法来跟我讨论,基于此,我自然要先弄清楚你的标准或者你的想法是否符合我的标准和我的想法,如果我们对标准的定义都不一致,那有啥可讨论的呢,而且我的标准我在上面的回复中已经反复而且清晰的提到过,所以我说我们之间是“没有标准的争论”有何问题?

OK,这里可以说是我的理解问题,我以为你是指这个划分没有标准,而不是没有划分标准的数据/方法 支持

这也相当搞笑,且不是我没有明确表达是否认可你的联想,即便我不认可,有怎么能得出“没有联想能力”这个结论呢,这也并不是什么高明的联想吧,游戏引擎组件设计基本都是“组合模式”,这种模式设计中有清晰的定义的东西无需任何其他的比喻来再次说明一次

嗯,所以你说的这句话是对的,我们应该把所有属性都放在 node 里面

所有有经验的程序员都是从没有经验的程序员过来的,自然能知道没有经验的程序员中的自己这个类型是什么样子的

嗯,所以我说的是错的,现在论坛一大堆新人反馈找不到自己想要的属性

你这是典型的谬误滑坡,我之前把所有属性都单独做成组件的假设就是为了让这种谬误滑坡显性化来表明这种想法是错的,所以你这句反讽却是用错地方了,我们在这点上没有分歧,都不应该谬误滑坡,而是就事论事

我说个,node有哪些属性是取决于node是什么的,我不认为加上opacity和size两个属性node的属性就爆炸了,如果定义清晰,找不到想要的属性也很奇怪,我从1.x用到3.x也没觉得node的属性数量有剧烈的增减,常用的属性就那么几个,不常用的一下找不到跟设计没有关系,任何设计下不常用的属性都很难找到,分了组件还得自己自己要的属性在哪个组件里,岂不是更难找到
这个只针对node的属性来说,毕竟现在官方也没公开发表说明有多少新人吐槽找不到node上的对应属性,这些属性是哪些,为啥找不到,这些新人占整体新人的比例是多少,是否需要为了这些新人而做出改变

个人倒是希望引擎官方可以在新建节点时提供一个下级对话框,让用户做一些基本的配置(最好是此配置面板可以开放接口做插件),比如创建node可以选择直接添加UITransform和UIOpacity什么的,创建ScrollView的时候可以直接添加用户自定义的addItem乃至addWeapon接口……

最后针对标题我再回复一句,2.x 的 childrenCount 在 3.x 已经没了

UITransform和UIOpacity这两个组件太特殊了,作为node的属性存在会在使用时更加方便也更加自然,毕竟一个节点没有大小和透明度那这个节点是什么就很难说清了。
UITransform可能是出于一些设计做出的妥协吧,node有Scale和Rotation却没有Size,总感觉奇怪。
UIOpacity我觉得应该是临时性的,可能目前有些问题还没解决,因为Color中有透明度选项,而Color又更多跟渲染组件绑定而不能作为node的属性,导致不好协调。
至于ScrollView我觉得官网出一个新的组件专门做背包类功能更好点,https://github.com/gh-kL/cocoscreator-list 这个库我觉得就特别好,可惜官方没吸收,靠作者维护在Creator升个版本就大改一次的强度下,很难跟上最新版本
如果创建一个组件需要做选择还是挺麻烦的,就像现在创建一个组件给了个改名机会必须多一步操作改变焦点才能创建出来这种画蛇添足的修改就用着挺难受,官方可以提供创建模板给用户自定义创建过程可能更好点

现在好像无法扩展层级管理器菜单,期待一个引擎官方开放层级管理器菜单扩展吧,消息里现在貌似也缺少获取选中节点的接口不好通过主菜单简单实现


哎,官方有很多基础设施一直没做好,也不愿意收编有潜力的第三方,tiledmap都多少年了也是大小问题不断,希望后面的更新能完善吧。
到现在引擎的运行预览环境主要还是浏览器,但就是不愿意把运行时的节点树加上,第三方插件不是收费就是跟不上Creator的版本,3.x一来多少好用的插件瞬间归零。unity一开始就有的东西Creator这么多年都没有,还是不重视。
第三方插件如果是购买内容用户无话可说,可是像运行时节点树,状态机行为树编辑 这些基础设施都要花几十到几百去买插件用,这个生态就显得很畸形。官方应该花钱收编,而不是把成本转嫁到用户身上