traitCollectionDidChange isn't necessarily called on Main, but our self.backgroundColor property access must be done on main once the view is loaded.
I originally opted to use self.backgroundColor rather than _backgroundColor in #1674, but I think we should use the ivar here. This could get out-of-sync if someone modified the UIView's background color instead of updating the node, but I think that's unlikely, so we should be safe to use the ivar here.
- Address various issues with tint color on text nodes
- Avoid accessing `self.tintColor` off-main since this will trigger an
assertion and might be undefined behavior
- Trigger setNeedsDisplay in cases of hierarchy change and
tintColorDidChange in ASButtonNode, ASTextNode{1,2}
- Fix bug in _ASTableViewCell where we were overwriting the tint color
instead of inheriting the correct value
- Add tests for new logic in changing hierarchy
* This PR addresses an issue I raised with #1673 where the clipping corner layer doesn't get re-rendered when going from a dark to light user interface style. The fix is to add code in the `-asyncTraitCollectionDidChangeWithPreviousTraitCollection:` method that calls through to `-_updateClipCornerLayerContentsWithRadius:backgroundColor:` if the user interface style changes.
I've also added snapshot tests to verify that using clipping corners with a dynamic background color updates when the user interface style changes.
* ASImageNode tintColor improvements.
When ASImageNodes changes tintColor or enters the hierarchy, ensure -setNeedsDisplay is called if the image is templated.
Add unit tests to ensure this behavior works.
* Node TintColor Tweaks
- If the tint color changes, be sure to call -setNeedsDisplay on the view.
- Explictly declare tintColor ivar and getter method.
- If the tintColor is the same as the existing one, early-exit.
- Use the ivar and not the property when setting the tintColor, just as is done for background color.
- Add tests (for non iOS13 and iOS13) that the tintColor will call -setNeedsDisplay
- Backfill tests to document/verify the tintColor behavior on a node.
There is a potential dealloc race condition that can occur when attempting to perform work with image asset out of the main thread. Moving that work into the image node draw loop if necessary
* Update ci.yml
Add name to the script run phase
* Revert back Dangerfile and remove danger JS, create separate workflow for push for tests and for PR for tests + danger, run ruby danger as part of the PR check
* remove PR ci
* Revert "remove PR ci"
This reverts commit 839ba3ae2a.
* cahnge token to default one
* PR feedback
* Rename danger.yml name
- Fix availability warnings for usage of userInterfaceLevel
- Deprecate `asyncTraitCollectionDidChange` in favor of the new method
- Remove old compiler warning flag added for Xcode 9 building
- Access `textColorFollowsTintColor` with a locked scope
* Fix issue where UIGraphicsRendererFormat is mutated
As part of https://github.com/TextureGroup/Texture/pull/1629, we use the
preferred or default UIGraphicsRendererFormat. This was pointing to a
static variable which content scale was mutated across several graphic
render passes and lead to pixelated views.
* Update reference images with iOS 10.3
To preserve dynamic color capabilities for layer-backed
nodes, we need to track backgroundColor as a UIColor. In layer backed nodes we lose the dynamic color logic since we
extract a CGColor from the UIColor applied to ASDisplayNode. With this
change we can respond to changes in UITraitCollection.userInterfaceStyle
for backgroundColor.
Currently ASImageNode would initially load the correct asset from the asset catalog but would not respond to changes in trait collections that would require loading a different asset from the asset catalog. This change allows use to use `-[UIImage imageAsset]` to reference the asset catalog entry for the current image and load the appropriate version based on the current trait collection
- Adding experiment to propagate older trait collections when trait
collections change
- Re-render nodes when user interface style changes (dark mode)
- Snapshot testing examples for dark mode
- Fixes for applying trait collection overrides in XCTest
- Create new define for gating Xcode 11 / iOS 13 features until CI is running it
* Allow full color tinting on grayscale template images.
* Signing a commit with the correct email address.
* Add snapshot test for a grayscale image with ASExperimentalDrawingGlobal enabled.
Turned out that @babel/plugin-transform-flow-strip-types is needed for TypeScript/Bale transpilation with we don't need because we use JS. So instead of installing the module, we can. just disable transpilation by DANGER_DISABLE_TRANSPILATION environment variable to true.
Test plan: Tested manually here: https://github.com/TextureGroup/Texture/commit/a4cfe347914c23aafe08603bf82372d4cb94136c/checks
In #1627 I introduced an approval step that is meant to block PRs from forked repos unless they're labeled as "CI approved" by a maintainer. Turned out it doesn't work. When a label is added, a pull_request event with "labeled" as its action is fired but GitHub CI didn't restart the workflow. My guess is it checked the PR's commit and branch and determined that nothing has changed. Here is what the doc says: "A workflow runs on a specific version of code in your repository, determined by the commit SHA and Git ref" (https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events).
This diff removes the label check so all PRs are automatically built. Here are the current usage limits in case we run into them: https://help.github.com/en/articles/workflow-syntax-for-github-actions#usage-limits
GitHub Actions now supports CI and it's free for open source projects!
Our current CI runs on a single machine and needs 1h 20m for each build. GitHub CI often finishes everything in less than 10m!
The setup is straight-forward. The only missing feature is the ability to exclude certain files so that if a commit only contains those files, the CI won't test it at all (see exclude-from-build.json). Given that GitHub CI is fast and is not a serial queue, I wouldn't mind testing such commit as well.
* Fix and optimize steps that build example projects
- examples-pt3 builds the same examples as examples-pt1 instead of building the remaining projects. So I fixed it.
- Add another mode (examples-pt4) to distribute the load with existing steps.
- Build extra examples (examples-extra-pt{1, 2, 3}) which weren't built before.
- Each examples-pt and examples-extra-pt builds 5 projects except examples-pt4 and examples-extra-pt3 which build 6.
* Use HTTPS URL for Weaver in Podfile of examples/ASDKgram
* Don't build extra examples for now
* Add support for tinting layer-backed ASImageNode's
* Move tint color support ASDisplayNode
* Address comments, unlock before calling "tintColorDidChange" on
subclasses
* Address comments
We rely on the delegate setter to be called to set the flag. However, recent change on iOS 13 causes the setter to not be called at all and thus we had to put up a workaround (https://github.com/TextureGroup/Texture/pull/1609). While the workaround works, the perf benefit of that the flag provides doesn't warranty the extra complexity IMO. So I think we should just remove everything.
- Add the ability to specify a tintColor for images / buttons that behave similarly to how they would under UIKit.
- Add flag to control if tint color is applied to ASTextNode to match how
UIKit controls if it is .applied to UILabel.
- Update tests for not-tinting automatic render mode for UIImage.
- Add property on ASTextNode2.
- Add tint color support to ASTextNode2.
It appears that UIKit might be setting the delegate ivar directly which bypasses establishing the `_delegateFlags` ivar on `ASDisplayLayer`. This is critical for things like ASPagerNode, ASCollectionNode that depend on layer delegateFlags to forward bounds changes.
Radar filed: FB6956185
We previously tried to optimize showing animated images (e.g. GIF) by calling
display link for updating the frame just when when we need the next frame, but
this resulted in some frames dropping when `frameInterval` wasn't respected like
you can find from this GIF:
https://i.pinimg.com/originals/58/9c/e8/589ce828d2ef0797da0e85b1c6d2f2b3.gif
Since the the display link fire method continues if we detect we're
at the same image index as before, let's just remove this optimization.
If the alwaysHandleTapTruncationAction is YES, the ASTextNode and ASTextNode2 can handle touches on additional attributed message even passthrough is YES.
Our pages are organized in 2 dirs: /docs/ and /development/.
Within a dir, prevPage and nextPage are relative (to the dir) so its path should be appended to their href links (see docs/_layouts/docs.html). The dir is available in the page's permalink var.
Some prevPage and nextPage point to a page in a different dir in which case they must not be relative. Instead they must include the other dir's path and thus their links won't be modified.
Also removed some pages that are no longer needed and fixed some prevPage and nextPage values.
I tested this diff locally and all links worked fine.
* Update .gitignore file [Carthage]
* Add Cartfile.resolved file
Quoting from Carthage's README.md on Github:
"Along the way, Carthage will have created some build artifacts. The most important of these is the Cartfile.resolved file, which lists the versions that were actually built for each framework. Make sure to commit your Cartfile.resolved, because anyone else using the project will need that file to build the same framework versions."
Vlad Solomenchuk
Rahul Malik
Hanton Yang
Harry Shamansky
Mike Donahue
Greg Bolsinga
Michael Zuccarino
Jakub Kašpar
Jessie Alvarez
Huy Nguyen
Michael Schneider
Ray Sang Hyuk Cho
dirtmelon
