Expose EasingCurve
I'm writing this PR so we can discuss whether we should expose i_slint_core::animations::EasingCurve in the Rust public API. The rationale is that since #9179, we can define structs in Slint code containing fields of type easing and that may lead to the need to construct such structs from Rust code.
But there are some open questions that should be answered first:
- Is exposing
EasingCurvedesirable? - Should we include as variants of the enum all names present in the
Easingnamespace, since currently it has only a few? - How that enum should map to each of the languages Slint has bindings to?
- Is exposing EasingCurve desirable?
Not sure about that. I think for a complete API that might be worth it. But I wonder if there is any actual use case for it.
- Should we include as variants of the enum all names present in the Easing namespace, since currently it has only a few?
Perhaps these should be associated const ?
How that enum should map to each of the languages Slint has bindings to?
That is a good question.
In Rust, the lazy way would be just to expose the enum as is. Although for future proof we might want to hide it behind a type like struct EasingCurve(EasingCurveInner)
Not sure what to do in C++/JS/Python.
Overall, I am not sure if it is worth the effort without seeing good use case for it.
We have plan to expend animation to Spring and other curves and maybe it would limit us if the type is exposed as is.
I think it would make sense to expose EasingCurve. However, I think the API needs a few changes:
- [ ] The enum needs to be non-exhaustive.
- [ ] It should not be
Copy(esp. in light of adding new variants the future that aren't easily copied). - [ ] Bézier curve variant should use structure syntax instead of an array to give the control point coordinates names.
I think it's okay of this is only available in Rust initially.
Perhaps we should wait for a real use case to appear? This way it may become clearer the best way to expose the enum (including how to expose it in the bindings to other languages).
I think it's okay of this is only available in Rust initially.
I'm not familiar with the API in other languages. Do we have other cases where the API of the bindings lags behind the Rust API?
I'm not familiar with the API in other languages. Do we have other cases where the API of the bindings lags behind the Rust API?
Unfortunately yes. Some API are added first in Rust, then we "forget" to add bindings to it.