- Replace is null usages in generated code with downlevel equivalent to support older versions of C# in client applications
- Fix MSBuild task to send bool args correctly. The LottieGen cmdline only allows flags to be set without an associated value arg.
* Added support for animated round corners modifier
* Fixed typo and epsilon calculation
* Typo fix [2]
* Added new issue code LT0043 + more comments in the code
- Parameter validation no longer fails on valid params
- Fixed props fle path to LottieGen dll
- Fixed path generation for LottieGen exe
- Converted parameter types which are not supported by MSBuild to acceptable types
- Added escaping to command-line args to avoid mangling file paths
Error reported:
Microsoft.Toolkit.Uwp.UI.Lottie v7 uses System.Text.Encodings.Web v4.7.1 which has a high severity security vulnerability and as such doesn't pass component governance
This upgrades all of the runtime NuGet packages to the latest version.
When using the "-AdditionalInterface" parameter in LottieGen (which causes the generated code to declare that it implements interfaces that it otherwise doesn't know about), the interface needs to be known to the generated IDL file.
There are 2 ways that the IDL may know about the interface:
1. The interface may exist in a .winmd file that is referenced by the project.
2. The interface may be defined in the project using an IDL file.
LottieGen doesn't know which case the user requires. Previously we were assuming case 2 which causes problems if the interface is not in an IDL file.
Rather than requiring the user to tell LottieGen which case is being used, we know wrap the import in a condition that depends on the existence of the file. This should handle both cases seamlessly.
* Tweak the nudging factor for markers, and better UI for markers.
These changes are to improve AnimatedIcon workflow.
The nudging value of 0.01 was insufficient, so this ups it to 0.05.
The UI in LottieViewer for markers and the scrubber is confusing because it shows progress, which designers don't care about. So now it uses frames everywhere. Developers that need to convert to progress can do the math themselves (it's just (frame count) / (number of frames) plus a nudge.
* Make the arrow keys on the scrubber move by a single frame.
* LottieViewer UI now only deals in frames.
Seeing as LottieViewer is for designers, and they don't know about progress, the markers and scrubber will now only show frames information.
Also added more frame information to the Lottie properties.
Arrow keys now move by a single frame on each press.
* Fix the colors on hyperlinks and the playback rate slider.
The default colors for hyperlinks and sliders are themed, which can cause the colors to become unreadble on the gray background of the main page..
This is mostly a find-and-replace of the == null and != null checks.
This makes the code consistent, modern, and safe from equality overloading errors.
I have not replaced them in the generated code.
I have made the C# generator output the "is not null" pattern.
* Fix some missing simplifications in Composition expressions.
The logic for determining whether an expression could be simplified was sometimes wrong because it ended up hitting an overridden equality operator which compared the already-simplified values.
Also fixed the test script to look at last write time when determining which is the latest build of LottieGen.exe to run. We were looking at creation time, but it turns out that when the compiler builds, it doesn't cause the creation time to be updated if the output file previously existed. Our test script could accidentally use a release build when the latest build was actually a debug build, resulting in the test running on an old build.
* Replace the IsAtomic bool with a more generalized Precedence concept.
Without this, it was getting unwieldy to handle all the cases of precedence. Now we're removing parentheses more aggressively, so the expressions will be more efficient to parse.
* Eliminate some unnecessary whitespace in Min and Max expression functions.
This makes it much easier to figure out what is causing issues in animations.
Also remove the "readonly" on properties in the generated C# because they aren't supported by the language versions used in UWP.
* Nudge the markers forward by 1/100 of a frame to stop flashing.
Due to floating point imprecision, a marker value may refer to the previous frame, which causes flashing for AnimatedIcon.
This change is a test to see if it helps the problem. If it does, it needs a little more tweaking so that the frame numbers in the comments don't look whacky.
* Remove the decimal place from the frame number. Frame numbers from Lottie are always integer values.
* Remove accidentally added "using".
* Fix bug in visibility optimization.
This was causing some things to be visible when they were not supposed to be.
While I was there I refactored the the types that are used to calculate visibility to make the code a bit easier to understand.
Previously, you'd press the arrow keys 10 times before the tooltip value would change. That was confusing! Now the tooltip will always change in response to the arrow keys.
With this change, we'll produce a new nuget package that contains the LottieGen.exe executable built into a single file with no dependencies (not even .NET) and an MsBuild task.
This is being done to enable LottieGen to be more easily used in a build.
* Create a project just for the animatables.
The animatables are types that are used by both LottieData and the upcoming
intermediate representation, so we need them to be in a separate project so
the code can be shared.
This also adds some small features to some animatables for use by IR, and
changes some IAnimatableVector3 types to IAnimatableVector2 (e.g. gradient
stops should never by vector3.
I've also removed the "property index" from animatables. That is a Lottie concept
that is only needed if you are supporting javascript expressions. We will never
support javascript expressions, so they're not needed. Removing them makes the
code a bit cleaner.
* Add support for WinUI 2.6 animated icon.
This also removes the ability to set a custom interface in place of the WinUI
interface, because nobody seems to need it now, and it adds a bunch of
complexity.
Animated gradient brushes are expensive to render. This change allows us to see the gradient brushes in the DGML graph representation, and colors the animated ones in a very obvious red color.
The code we were generating for cppwinrt had a couple issues when compiled for Win32 (vs UWP).
1. It included a file that cppwinrt doesn't generate for Win32.
2. It was relying on Windows.Foundation.Collections.h being included by something else.