Add stretchable sprite component and corresponding sample

[ricab]

No scripting bindings ATM. Help with those would be great. Code review and testing would also be appreciated.

Making StretchableSprite2D inherit from StaticSprite2D was the easiest way to avoid code duplication, but it meant inheriting several "degrees of freedom" (e.g. manual hotspot, draw rect, spritesheet, flips), with many combinations that I could not test.

See related discussion in https://discourse.urho3d.io/t/stretchable-sprites/3842

[ricab]

Scripting bindings done (both AngelScript and Lua)

[ricab]

Hi, I did part of this outside of my normal dev environment and just noticed that my editor introduced a bunch of white space errors. They are now fixed in the last commit.

[weitjong]

Thanks for your PR.

[ricab]

Thank you @weitjong! And sorry for the formatting differences. BTW, do you use any formatter tool with a Urho-compatible profile? Cheers

[weitjong]

I have customized my IDE (Clion) to match the existing code style some years back and now just invoke the IDE to format for me. Still need to manual adjust it afterwards though. So, it is still not perfect. In future we will employ Clang-Format to check the code style when the PR is being raised.

[ricab]

Note: coverity reports 4 new null ptr dereference defects in generated code for lua bindings. I believe they can be safely ignored as they are the same as for other Urho2D components (that particular file has 641 issues). Also, some null ptr checks are done beforehand (unless TOLUA_RELEASE is defined). Let me know if they should be marked ignored, I can do that (assuming I have permissions).

[weitjong]

Yes, you can safely ignore them. Probably it makes sense to setup the scan without the tolua++ generated code for now to remove all those defects reports from coverity scan, instead of going though them manually.

[weitjong]

The last scan without Lua build option enabled and hence without those tolua++ generated code has surprisingly drastically eliminated 6,160 defects in one swoop. We have left with 1,005 outstanding defects (this number probably including those from 3rd-party) and brought our defect density down to 0.74.

If you are still interested in having the permission to classify the defects in our coverity scan defects report then you can apply it via an online form provided in their web interface. Once I receive your request, I will be gladly to approve it.

[ricab]

Great, that is some improvement :)

I just tried classifying a couple of issues and it seemed to work. Could you confirm you see it? e.g. issue 216066 (hope the link works).

Please notice that some of this stuff is subjective enough to engage in whole holy discussions (RAII, premature optimization, etc.). So let me know if the approach I took in that case is welcome or not - I could write a TrailPoint ctor or just leave it be.

[weitjong]

I can see that CID has been classified by you. Just check the member list, you have been accepted as the last member since May 15 2017 😄

About the false positive. Yeah, that is the main reason why we had sort of abandoning it after we successfully set it up. Although once in a while the scan report does reveal genuine defects. So we still want it to make it to become useful some day. Having someone to help to classify remaining outstanding issues will be awesome.

About the "uninitialized variable" issue, we do get that as the lint error from clang-tidy as well if version 5 or 6 is being used. As I mentioned before somewhere else, I have a plan to upgrade the current clang-tidy version to the latest version 6 (as Clang 6 release is imminent). So, we have to deal with it one way or another.

[weitjong]

If you are serious about helping us to classify and fixing the genuine defects then I suggest you raise another new issue in our issue tracker to keep track of your progress and to make your work more visible. And when/if you could generate PRs faster than we could review/merge them then we can also grant you the push privilege directly.

[ricab]

Yes, well, I can't devote much time to it, but I was thinking of doing a couple once in a while, on the assumption that little is better than nothing 😁 I am about to submit a PR with a fix for 4 issues in RibbonTrail.cpp. Let me open that issue as you suggest then.

Having a pair of eyes on PRs is useful for the moment indeed, at least until I come to grips with the formatting.