Skip to content

Conversation

gustavo-hms
Copy link
Contributor

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:

  1. Is exposing EasingCurve desirable?
  2. Should we include as variants of the enum all names present in the Easing namespace, since currently it has only a few?
  3. How that enum should map to each of the languages Slint has bindings to?

Now that we can create structs containing easing curves in Slint code,
it may be necessary to construct such structs from Rust code. For that,
the EasingCurve enum should be exposed as part of the public API.
@gustavo-hms gustavo-hms changed the title Expose easing curve Expose EasingCurve Aug 22, 2025
@ogoffart
Copy link
Member

  1. 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.

  1. 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.

@tronical
Copy link
Member

tronical commented Sep 9, 2025

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.

@gustavo-hms
Copy link
Contributor Author

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).

@gustavo-hms
Copy link
Contributor Author

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?

@ogoffart
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants