Adds some cleanup to this previous PR: https://github.com/rive-app/rive/pull/5411/files
- Brings back some classes and parameters and mark them as deprecated.
- Changed the naming for parameters
- Removed asset resolving from the high level `RiveAnimation` widget, prefer to manage this by loading in your own `RiveFile`. This is to avoid introducing too many changes that we may revert down the line
- Removed code comments that were intended as questions, marked some as TODOs
- Improved documentation and cleaned up example
The cached asset example now has a button to hot swap out assets at runtime by keeping a reference to the asset. This works for images, but not for Fonts.
- We can either remove this example for the time being
- Or investigate why it does not swap out (I would expect it to)
Diffs=
94e3490ae refactor: asset resolving (#5563)
bae069339 Stop automatically pruning empty segments in RawPath (#5557)
2d2d8c413 Line Height & Paragraph Spacing (#5552)
Co-authored-by: Gordon <pggordonhayes@gmail.com>
There are a number of questions I'd like to resolve before considering to merge this. also a few thigns to clean up no doubt
# Questions before merging
To customize loading out of band assets, we expect our users to implement
```
abstract class FileAssetLoader {
Future<bool> load(FileAsset asset);
bool isCompatible(FileAsset asset) => true;
}
```
1. is this a good interface (i've changed `loadContents`, to `load`)? (if we like this we should change this in cpp too)
2. `FileAssetLoader` is a mouth-full, would `AssetLoader` be better?
3. We are passing `FileAssets` (our core objects) to users with some slight api extensions, is that good? should we just wrap this in an Asset class (I had this before, its not a lot of work to get it back)
things sorted
- [x] cdn "loading" vs url loading
- just sticking with cdn, users can customize for url
- [x] asset class for consumers of our runtime.
- i've avoided this one for now, just extending our FileAsset
- [x] Importer/Resolver/Loader. I flipped some names around, mostly because I want our end users to provide an `AssetLoader`, not a resolver.
things to sort out down the line, i'm declaring them out of scope for this pr, fft disagree:
- Fallback font, I see we have a fallback font file hardcoded in the runtime. should investigate if we can include an asset for people like this, or if we need to have users set this if they want to use fallback fonts.
- Image Placement, we should strip width/height from runtimes on ImageAssets
- What do we want to do about asset loading / decoding errors
- TextStyle has both assetId & fontAssetId it gets assetId from the file asset referencer, its nbd,
Diffs=
06e959ad2 Font dart runtime (#5411)
Co-authored-by: Maxwell Talbot <talbot.maxwell@gmail.com>
