What are the specific issues regarding the use of for..in statements inside Paths?

[SparkyTD]

I was trying to dynamically construct a path with a for-in statement to emit the path commands, but I ran into a compiler error referencing #754. Is this due to a limitation in how paths are currently handled, or is it simply something that just hasn't been implemented yet?

Looking at the code for the path compiler, the only reason I can see is that the path segments seem to be constructed statically by the compiler itself, whereas using for loops may rely on runtime-dependent dynamic data.

The reason I'm making this post is because I was thinking of making an attempt to implement this feature myself, but I would like to get some insight from the maintainers first, since I am still new to this project and its codebase.

Maybe we could start with allowing hard-coded ranges (e.g. for i in [1, 2, 3]: LineTo{...}) where the number of emitted elements doesn't depend on dynamic data bindings? This would still be useful for generating e.g. background grids for a graph.

[ogoffart]

This just isn't implemented.
We'd need to assign the Path's runtime item with an elements Expression that loop over the model to create item.
(Add a repeated: Option<Expression> with the model in i_slint_compiler::expression_tree::PathElement?)
And then lower that to the right code so that it works at runtime.

[SparkyTD]

Thanks for the reply! I would like to implement this, but I am still familiarizing myself with the codebase, and I might need some additional guidance.

I started implementing the feature based on your suggestion, you can see my progress here: feature/path-loops. This seems to emit the correct code with seemingly correct bindings to the loop model, but the compiler panics during the move_declarations pass with the following message: Repeated element should have a component as base because of the repeater_component.rs pass.

I hope I'm not being a burden by asking these questions, I just really want to get this feature to work because of my use case.

[ogoffart]

cool!

I think you're seeing the panic because the element is still repeated in the optimized_elements.
You can do something like that: let repeated = child.borrow_mut().repeated.take(); to remove the fact that the element is repeated from the object_tree, you only need this information in the Path.

[SparkyTD]

I'm not sure if taking instead of cloning would actually fix the issue, because doing it that way will cause this assertion to panic during an earlier pass. I am currently trying to get a deeper understanding of how these loops work in the supported cases (like repeated Rectangle elements), and see if I can apply that to Path.

Right now it seems like the error is caused by this, because in case of repeated path elements, the base_type of the element here is actually ElementType::Error for some reason, and not ElementType::Component(...), which would be the case for supported loop types.

[SparkyTD]

I have given up on implementing this myself, because I can't make any meaningful progress. For the time being, I will try to use a custom OpenGL renderer (based on #2767), and use an external SVG library to render more complex Paths.