You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calls to Composition inside of ImplicitAnimationSet were causing the ColorPicker to fail to show on Wasm in this PR. We're referencing the Animations component for ImplicitAnimationSet, but implicit animations use Composition, which aren't implemented on Uno yet.
Our options were to either:
Add conditional XAML everywhere ImplicitAnimationSet is used, or
Update ImplicitAnimationSet to avoid calling Composition APIs when running under Uno until support is added.
Can we combine conditionals with a namespace like that in Uno?
Official Uno docs recommend wrapping it in a container such as a Grid. That requires adjusting the Visual Tree in a lot of different places, both in our codebase and in the codebase of those consuming our packages
We do need a better way of tracking what's not supported in Uno though doing it that way, right? As it's not like we'd have it throw an unsupported exception.
At a high level, our custom MultiTarget system is designed to mitigate this happening on accident by allowing us to isolate code that depends on unsupported APIs (e.g. Composition) into separate libraries (e.g. Media) and disabling Uno-specific MultiTargets so they can't be used without first adding support and checking/addressing the original reason for lack of support.
When we enable Uno for a component that didn't previously support it, we need to be doing a sweep of the component to make sure nothing throws when running under the new platform.
The problem
We didn't originally support the wasm MultiTarget for Animations, but we added *partial* support for running on Uno through the FrameworkLayer abstraction, though this support only extended to AnimationBuilder and CustomAnimation. Other code is still in place that calls to the Composition APIs on Wasm, which will throw out of the box.
Giving the Animations package a quick once-through, I've also noted that:
CustomAnimation isn't being used by our inbox animations (TranslationAnimation, ScaleAnimation, etc) despite inheriting the same type. They won't default to FrameworkLayer.Xaml on Uno.
Implicit/Explicit animations and helpers are still using Composition APIs directly without handling what to do when running under the added Uno tfm
The solution
The above isn't an exhaustive list. We should do a full sweep of the Animations package to see what can either:
Be implemented without using Composition (if needed enough), or
Be disabled so it doesn't throw when people use it, while we wait for Uno to implement Composition.
Background
Calls to Composition inside of ImplicitAnimationSet were causing the ColorPicker to fail to show on Wasm in this PR. We're referencing the Animations component for
ImplicitAnimationSet
, but implicit animations use Composition, which aren't implemented on Uno yet.Our options were to either:
ImplicitAnimationSet
is used, orImplicitAnimationSet
to avoid calling Composition APIs when running under Uno until support is added.Official Uno docs recommend wrapping it in a container such as a Grid. That requires adjusting the Visual Tree in a lot of different places, both in our codebase and in the codebase of those consuming our packages
At a high level, our custom MultiTarget system is designed to mitigate this happening on accident by allowing us to isolate code that depends on unsupported APIs (e.g. Composition) into separate libraries (e.g. Media) and disabling Uno-specific
MultiTarget
s so they can't be used without first adding support and checking/addressing the original reason for lack of support.When we enable Uno for a component that didn't previously support it, we need to be doing a sweep of the component to make sure nothing throws when running under the new platform.
The problem
We didn't originally support the
wasm
MultiTarget forAnimations
, but we added *partial* support for running on Uno through theFrameworkLayer
abstraction, though this support only extended toAnimationBuilder
andCustomAnimation
. Other code is still in place that calls to the Composition APIs on Wasm, which will throw out of the box.Giving the Animations package a quick once-through, I've also noted that:
CustomAnimation
isn't being used by our inbox animations (TranslationAnimation, ScaleAnimation, etc) despite inheriting the same type. They won't default toFrameworkLayer.Xaml
on Uno.The solution
The above isn't an exhaustive list. We should do a full sweep of the Animations package to see what can either:
Originally posted by @Arlodotexe in #241 (comment)
The text was updated successfully, but these errors were encountered: