Skip to content

Add angle-aware interpolation modes for animations#10453

Open
task-jp wants to merge 4 commits intoslint-ui:masterfrom
task-jp:angle-interpolation
Open

Add angle-aware interpolation modes for animations#10453
task-jp wants to merge 4 commits intoslint-ui:masterfrom
task-jp:angle-interpolation

Conversation

@task-jp
Copy link
Contributor

@task-jp task-jp commented Jan 15, 2026

Add interpolation property to animations with support for:

  • linear (default): Standard numeric interpolation
  • angle-shorter: Take the shorter arc for angle values
  • angle-longer: Take the longer arc for angle values
  • angle-clockwise: Always rotate clockwise
  • angle-counterclockwise: Always rotate counterclockwise

This is useful for transform-rotation and other angle properties where the interpolation path matters. For example, animating from 10° to 350° with angle-shorter will rotate 20° counterclockwise instead of 340° clockwise.

Similar to Qt's RotationAnimation.direction and CSS hue-interpolation-method.

@tronical
Copy link
Member

This seems like a cool idea.

That said, I don't feel very comfortable with "interpolation" as enum name. That is very generic for something very specific.

I wonder if another way would be to provide a filter function for the interpolation (a way for users to specify). After all this adjusts start/end and bounds, but the interpolation remains linear, no?

cc @NigelBreslaw

@NigelBreslaw
Copy link
Member

Just wondering about how this makes the animation API more complex for all types, but this only helps angle animations? Although it puts the burden back to the developer, you can still achieve the desired animation today by using positive or negative angles?

@task-jp
Copy link
Contributor Author

task-jp commented Jan 17, 2026

My usecase is to animate needles in analog clock. I took interpolation from hue-interpolation-method from CSS. Would it be better to have just type instead?

animate angle {
    type: angle-shorter;
}

I would also like to add other types of animation such as color in various color spaces in the future.

@tronical
Copy link
Member

The animate keyword is associated with properties where the type is known. We could make it so that an angle-interpolation-mode is only available when animating a property of type angle?

Copy link
Member

@ogoffart ogoffart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes total sense, but it shouls be forbidden to use on any type but angle.
We also can bikeshed the naming

let binding_expr = binding.BindingExpression();
let Some(expr) = binding_expr.Expression() else { continue };
let Some(qn) = expr.QualifiedName() else { continue };
let mode = qn.text().to_string();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also support things like interpolation: Something.foobar-interpolation
And we should IMHO say that we can't put any interpolation if the type is not angle.

Add `interpolation` property to animations with support for:
- `linear` (default): Standard numeric interpolation
- `angle-shorter`: Take the shorter arc for angle values
- `angle-longer`: Take the longer arc for angle values
- `angle-clockwise`: Always rotate clockwise
- `angle-counterclockwise`: Always rotate counterclockwise

This is useful for `transform-rotation` and other angle properties where
the interpolation path matters. For example, animating from 10° to 350°
with `angle-shorter` will rotate 20° counterclockwise instead of 340°
clockwise.

Similar to Qt's RotationAnimation.direction and CSS hue-interpolation-method.
Both easing_kind_identifier and interpolation_mode_identifier contain
"linear", causing an unresolved conflict in tree-sitter parser generation.
Add explicit conflict resolution to the grammar.

This pattern is consistent with Slint's design where the same variant
name can exist in multiple enums (e.g., Center in 5 alignment enums).
Add compile-time validation that angle-aware interpolation modes
(angle-shorter, angle-longer, angle-clockwise, angle-counterclockwise)
can only be used with properties of type `angle`.

This prevents misuse of angle interpolation on non-angle properties
like length or float, where the angle-specific behavior would not
make sense.
@task-jp task-jp force-pushed the angle-interpolation branch from 96ac754 to 08fa0cc Compare January 29, 2026 11:11
Instead of checking individual angle-* interpolation mode values,
reject the `interpolation` property entirely when the animated
property is not of type angle. This is simpler and more robust
since it handles all expression forms, not just literal identifiers.
@task-jp task-jp force-pushed the angle-interpolation branch from dc8a55c to df9343f Compare January 29, 2026 11:35
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.

4 participants