Widget Operations

[hecrj]

This proposal introduces the idea of widget operations in iced. A widget operation is defined as some logic that can traverse (and operate on) the widget tree of an iced application in order to query or update some widget state.

Rendered

[13r0ck]

Would it be possible to set the focus of a widget in the view? Just like setting the horizontal_alignment() for example

I do like the idea of IDs though, it would be ergonomic to be able to return a Vec of IDs and let the runtime use that to generate the tab cycle order

[hecrj]

Would it be possible to set the focus of a widget in the view? Just like setting the horizontal_alignment() for example

This is already possible by leveraging the Elm Architecture. All we would need is a "managed" implementation of the widgets (i.e. without any internal state).

I do like the idea of IDs though, it would be ergonomic to be able to return a Vec of IDs and let the runtime use that to generate the tab cycle order

The built-in focus operations will use the position of the widgets in the widget tree to pick the tab cycle order. However, it will be possible for users to build custom operations!

[13r0ck]

This is already possible by leveraging the Elm Architecture. All we would need is a "managed" implementation of the widgets (i.e. without any internal state).

Then why do these widget operations change the widget in the update, rather than staying consistent with the rest of the architecture and change the widget in the view? I worry that people will want to add more and more to the widget state, like storing the text of a button in the widget, until we are at a point where Iced is just like GTK etc where the state is broken up amongst the widgets, rather than being in the global state.

[hecrj]

@13r0ck It's unreasonable to ask users to handle every single widget interaction through the Elm Architecture. This would imply a message for every interaction.

Imagine a TextInput, if we removed the internal state completely, in order to use it in your application you would need to properly wire messages, state, and update logic for focusing, unfocusing, moving the cursor, pasting, selecting, etc. All of these are interactions that, currently, update internal state without notifying the application.

Operations are only meant to be used to update internal widget state. Operations cannot update the structure of the widget tree, only view can do that! Therefore, it is still unfeasible to create a widget that somehow retains view structure and exposes a mutation-based API.

[13r0ck]

Oh ok, I misunderstood your last message. Thank you for the clarification! :)

I guess this is more of a port than a command then, right? Commands in both iced and Elm always return a message when completed. In ELM ports don't have the same guarantee.

[hecrj]

@13r0ck Commands are not guaranteed to return a message in both Elm and iced. In fact, ports produce commands. I believe you are thinking of Task.