cocos2d-x 3.7.1 scale-9 sprite works different from the previous one

[ryule]

In new cocos2d-x, 9-patch functionality has been added to ui::Scale9Sprite.
But the changed code affects the way of working of the original Scale9Sprite.
(Reference commit: 0352a7a)

1. The Scale9Sprite works weird

because the following code:

• UIScale9Sprite.cpp:526
  • if(_capInsets.equals(Rect::ZERO))
• UIScale9Sprite.cpp:549
  • if(!capInsets.equals(Rect::ZERO))

For example, setInsetLeft/Top/Right/Bottom methods call updateWithSprite.
(setInset* > updateCapInset > setCapInsets > updateWithSprite finally)
If a series of setInset* method call is happened then
the above ifs will work as an unintended way.

I don't know why those if conditions needed exactly, but if they are for
9-patch functionality then the other condition check should be added such as
&& _isPatch9.

2. CCTexture2D contains private methods related to 9-patch sprite

• isContain9PatchInfo, getSpriteFrameCapInset, removeSpriteFrameCapInset, and addSpriteFrameCapInset.

Due to this structure there is no way to write and extend the codes that manage cocos2d::SpriteFrame as 9-patch sprites manually.
I think those methods mentioned above would be declared as public.

[zilongshanren]

@ryule
Thanks, I will resolve the issue 1, my bad.

For the issue 2:
At the first beginning, I designed all the APIs to be public. But @minggo suggest that there are no mandatory reasons for public these APIs.

Could you give an example? Or could we just make them as protected such that the subclass could use it.

Thanks.

[zilongshanren]

Hi, @ryule
Does the PR fix the 1st issue?
Thanks.

[ryule]

@zilongshanren, your commit 6cea66f fixed the first issue, thanks!

For the second issue, a stand alone texture cache manager that independent to the given CCSpriteFrameCache would be an example. The manager should have an access right to the methods related to 9-patch to make its functionalities intact.
Even with the protected methods, I think that the code cannot have a completely separated structure without helping sort of friend class things. If any other better way exist then it would be great.

Thanks.

[zilongshanren]

@minggo What do you think about public these APIs?
I don't like the friend class either as @ryule

[zilongshanren]

@ryule
For the second issue, we decide to not public these APIs. If these APIs are public, we should maintain them and it's hard to evolve when the design is not good enough. And these APIs introduce implicit dependency between SpriteFrame and Texture2D object, we still think these APIs are not suitable for public.

If most developers want these APIs, then we would consider public them.

Thanks.

[ryule]

Sure, it's fine. I really appreciate your effort for this issue.
Thanks, @zilongshanren.

[zilongshanren]

@ryule You're welcome.