Since ChildAccess is an enhancement specifically for Haxe that shouldn’t conflict with anything from the original Starling, I think that it’s fine.
I believe I’m done with the initial 2.7 update, for anyone interested it’s here GitHub - MatseFR/starling at v2.7
I’m gonna have a look at the differences between the 2.7 release and the current code on as3 starling, I think there have been additionnal commits.
Then I’ll look into the ChildAccess thing
3 Likes
I fixed a few issues on 2.7 branch (DisplacementMapFilter looking weird, Color.interpolate returning weird values)
I’m also done with the changes from 2.7 to the current as3 Starling Github, I created another branch : GitHub - MatseFR/starling at current-as3-starling
warning : I didn’t do the changes on AssetManager for mimeType detection (lazy + not comfortable tackling those as I’m unfamiliar with Haxe XML)
1 Like
ChildAccess class for Starling here starling/ChildAccess.hx at current-as3-starling · MatseFR/starling · GitHub
I grouped properties and methods for each class or my head would explode 
I put it in starling.extensions so it’s clear it’s not part of the original lib
There was a small update to TextField too, some stuff I missed in the previous updates.
1 Like
Wow, cool! Using Starling extensively, will definitely give updated version a try. Thanks for updating it!
BTW: there was a problem that leads to crashes on MacOs. Problem is specific to Haxe code generation, not starling itself: MacOs monteray: app crashes - #2 by Ilja_Razinkov
seems it is the same in your updated version (needs to be fixed), i can make a pull request if needed
1 Like
Thanks for the heads up ! I committed your fix (use an Array and use resize(0) instead of .length = 0)
Starling is great, it deserves a bit more exposure 
I’m not sure what more needs to be done now : I updated the source code and the haxelib.json file… what’s next ?
1 Like
Starling is great, it deserves a bit more exposure
Totally agree
I’m not sure what more needs to be done now : I updated the source code and the haxelib.json file… what’s next ?
Probably do haxelib register && submit ( Using Haxelib - Haxelib Documentation ) with the name like starling-hx (for example). Or get in touch with singmajesty / tbyrne / p.j.shand (contributors, mentioned here: https://lib.haxe.org/p/starling/ ) for making update to current starling haxelib.
Starling work great as is already, seems Air dev is also slowed down, so hopefully there will be no need for serious changes in future (anyway willing try to help since i’m using it and have no plans to switch).
Open a pull request?
I’ve been doing this on my github but the idea was to end up with a pull request to the openFL github
That being said, I think the situation on openFL starling has problems : for example the pull request that fixes the Std.is issue should have been merged long ago. It kinda feels like a ghost ship right now (no offense intended)
I don’t know how it works but I think we would need someone with an actual interest in Starling to have access to the levers on openFL-starling’s github. At least being able to merge pull requests.
Yeah, looks fine. Merged.
1 Like
Haha yeah, I should have specified “before opening a pull request”
I mean, I don’t know about NPM for example : I don’t use that, don’t know what needs to be done.
Also as Ilja mentionned : who has responsability for updating on haxelib ?
Should I just open a pull request from my latest code (the one that is on par with the as3 version on github) ?
Or should I open a pull request from my “v2.7” branch ? and then the “current” branch ?
Since 2.7 is a starling release, and “current” has changes that are not part of a release ?
Sorry if I over-complexify things, I’d like to do this in a proper and complete way if that makes sense. I would like to put the basic demo online for example, so people can have a quick look if they don’t know what Starling is about. Maybe adapt or create other demos/samples if there is an interest for it etc
Thanks, I was able to merge it (on my side) when I started working on this update so I have it already, hope it doesn’t mess things up
For the next release, Joshua would probably need to do it, but Chris and I can be added as contributors for future releases, like we were for Lime and OpenFL.
This is a good question. I would lean toward merging v2.7 first, and then we can release an equivalent 2.7 to Haxelib. Then, the “current” changes can be merged, but we should probably wait until Daniel releases the next AS3 Starling update before we release them to Haxelib too.
Let’s not worry about the npm version right now. We can revisit it in the future.
It should be fine. In my experience, Git is good about realizing that the changes are the same and not a conflict.
That would be great !
I agree 100%, let’s do it like this then. I have a few changes on “current” that should be on “2.7”, I can safely add them there and Git won’t scream when it sees them again in “current” I guess then
Thanks for your help Josh 
Ok I created both pull requests, I see a few conflicts maybe I should have wait for the second one… 
Why not adding ChildAccess to openfl Starling? It is a haxe language specific helper class.
It will not be a part of original as3 Starling. So no need to wait for Daniel)
Okay, the v2.7 PR is merged.
3 Likes
It’s still being added, just not part of openfl-starling 2.7, it won’t be there in the haxelib version for now but available from the github repository. I think it’s fine like this no ? I don’t mind if it gets added to 2.7 haxelib though.
It seems safe enough to add ChildAccess to v2.7. We might as well get it in there, since we don’t know when Daniel plans a new release of the AS3 version.
1 Like
Sounds good
issues that can be closed :
2 Likes