Summary:
Not re-calculate `paddingAndBorderAxisMain`/`paddingAndBorderAxisCross`/`paddingAndBorderAxisRow`/`paddingAndBorderAxisColumn` in Step1 of `YGNodelayoutImpl`.
They can be figure out by values calculated before.
Closes https://github.com/facebook/yoga/pull/298
Reviewed By: dshahidehpour
Differential Revision: D4365533
Pulled By: emilsjolander
fbshipit-source-id: 6caf60bc6ef3addd49915b39b48f01a8b4926e9c
Summary:
- Enable destructor unit tests in Unity Editor
- Exit pack.sh immediately if a command exits with a non-zero status
- Run unit tests before building Unity package
Reviewed By: emilsjolander
Differential Revision: D4365773
fbshipit-source-id: 20d0a51f4cef791154c17d329ac36598dc333a60
Summary:
This PR fixes issue #295
- Created a new internal YGNodeHandle class extending SafeHandle.
- YogaNode now stores a reference to YGNodeHandle.
- Removed finalizer from YogaNode.
- Pulling in System.Runtime.Handles 4.3.0.
Closes https://github.com/facebook/yoga/pull/297
Reviewed By: emilsjolander
Differential Revision: D4365462
Pulled By: splhack
fbshipit-source-id: 73293b105962cbedb71f4e3d8d1244251db1ea79
Summary:
- Change the CI config so it runs the tests for Editor on Sandcastle
- Don't run tests for effects-framework and yoga libraries when building for Mac (triggers code signing issues that I don't want to deal with right now)
- Add target for unit tests (aka EditorTests)
- Make the existing unit tests build and pass. These include both Objective-C and Swift (we should probably get rid of some of these though). I will convert these to Swift 3 before landing (after the migration is complete).
- Exclude the EditorUITests target for now. It only contains a single dummy test and it causes a code signing failure on Sandcastle. I did not manage to work around that yet but there is a separate task for it.
Reviewed By: Perspx
Differential Revision: D4352670
fbshipit-source-id: 0295004a72953bd8e7ae83895b2e5712bab7bd32
Summary:
Added Bash script and bat file to build a package of Yoga in order to import Yoga for Unity easily.
Closes https://github.com/facebook/yoga/pull/288
Reviewed By: emilsjolander
Differential Revision: D4344198
Pulled By: splhack
fbshipit-source-id: 49ae27dbc513b4a2d161840ca5c5f4c9df2ab227
Summary: Improve performance of allocations and reseting by writing fewer bits. Also just looks nicer imho.
Reviewed By: passy
Differential Revision: D4356994
fbshipit-source-id: ebbe52163e0c86230bfa4131b657941afe16fbf1
Summary: This should not be an enum. A define makes a whole lot more sense
Differential Revision: D4346529
fbshipit-source-id: 8641c4c5017d915d64e5884cae09ac8f01861337
Summary:
@public
AspectRatio is a new addition and soon after introduction we noticed use cases which is did not support. Specifically we wanted to support a node being as large as possible within a container while maintaining an arbitrary aspect ratio. This was not possible due to the low priority of AspectRatio, by increasing the priority of AspectRatio this is now possible as FlexGrow will grow an item to fit its parent unless the AspectRatio makes it too big in the cross axis, the AspectRatio will now override the FlexGrow in the main axis in that case.
Differential Revision: D4346720
fbshipit-source-id: 1f15613604190e3ad5ff4a467ba57db4bcfd2741
Summary:
@public
Aspect ratio being defined as width/height or height/width depending on the situation it was used in turned out to be very confusing. This diff makes aspect ratio always be defined as width/height irregardless of the usage.
Differential Revision: D4339132
fbshipit-source-id: e5da32750b55ddaf6acaf1cbd7662d86f2b480c3
Summary: We were incorrectly returning true for children which had no flex as the flex was nan and not 0.
Differential Revision: D4346712
fbshipit-source-id: 69ef0bb3fe5b4fcd3b3e2fe5aa348529be40252a
Summary: This test creates a repro case for Yoga to emulate UFI layout failure
Reviewed By: emilsjolander
Differential Revision: D4313632
fbshipit-source-id: 35be7d86b50a9ae08c81891a889a74e4b61f2d27
Summary:
There is a bug currently where we don't traverse the entire tree to detect view hierarchy changes.
Currently, if you had a hierachy like this:
```
container = UIView
container.subviews = @[subview1, subview2];
subview1.subviews = @[sub11, sub12, sub13];
subview2.subviews = @[sub21, sub22, sub23];
```
and then modified via:
```
subview2.subviews = @[newView1, newView2, newView3];
```
our algorithm wouldn't identify that we had new views that needed their layout calculated, and would cause a crash later on.
Reviewed By: emilsjolander
Differential Revision: D4357662
fbshipit-source-id: 2f61f213c5f1a62948a653f3b1fa3d874c5075f7
Summary: While building some views with YogaKit, I found an interesting problem. If you are apply `yg_` properties to a view which is constructed of subclassed views (that don't use Yoga.) we still treat view (and it's subviews) like they are using YogaKit. This fixes that behavior.
Reviewed By: emilsjolander
Differential Revision: D4348344
fbshipit-source-id: 37b8648918529f55afea1d1883a03af398aac849
Summary: I kept wrongly typing this function which is a good sign that the name is inconsistent.
Reviewed By: gkassabli
Differential Revision: D4333480
fbshipit-source-id: 17058f18fa9e26b3e02f7a1651f7295cae59acad
