Skip to content

Conversation

@SiebenCorgie
Copy link

I'm currently in the process of porting my custom iced renderer to iced-0.14.
I found that iced_graphics::layer::Stack only has iter but no iter_mut anymore.

I tracked the change down to this commit. My guess is, that it was not needed by both native renderers anymore. Whenever a (custom) renderer needs to mutate state while preparing or drawing a custom element in a layer, mutable access is needed to the layers in such a Stack.

That's why I propose to add back this function, that was already there in version 0.13.

Feel free to deny the PR, and if time permits tell me why that isn't a good idea. However, I'd rather merge such a small detail instead of maintaining my own iced fork.

Cheers!

@hecrj
Copy link
Member

hecrj commented Dec 11, 2025

I'd like to know why you need a mutable iterator to mutate state? Why does current_mut not work?

@SiebenCorgie
Copy link
Author

current_mut only returns a mutable reference to the top/active layer with no way to access the layers below it mutably AFAIK. For reference, in my renderer I'm at the equivalent of this stage, with the difference that the &layer.quads would need to be a mutable.

The reason for mutability is, that my renderer allows attaching foreign custom renderers that have to react to differences like layer-size changes or might change data in the perpare-stage for other reasons, which in turn needs to mutate state.

I guess a get_mut(index: usize) -> Option<Layer> or something similar would work too. Since iter_mut was already there I thought just adding that back is the easiest way.

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.

2 participants