Complexity of implementing a Flow/Node/Graph Widget?

Learn
1

I’m not very experienced with iced or really GUI at all. But I think this project seems great in many ways and would love to dig a bit deeper. I would like to port parts of a gui application using egui and egui_node_graph to iced for learning and evaluation.

I figured out that I could create my own “node graph” widget by implementing the iced::advanced::Widget generically on the iced::advanced::Renderer trait to support native renderers.

What I’m very confused about is how complex it would be to make this also work in the browser. I see that these kind of node/graph/flow libraries exists for react (e.g. https://reactflow.dev/) so I assume it is possible to do this with iced as well. Although when I open the documentation for dodrio it’s not clear to me how I would start to achieve this.

I’m unfortunately even less experienced in browser tech than native GUI, but if anyone have any good pointers/resources that explains how something like this could be implemented in iced (or the pitfalls I should avoid) I would be very happy to hear about it.

2

@tarkah implemented a graph editor as an experiment a year ago:

iced doesn’t rely on dodrio anymore. Instead, the whole UI is rendered to a canvas as if it were a native window. This generally means that you shouldn’t need to worry about cross-compatibility that much.

However, the Wasm target is a bit behind currently and has some issues.

3

In my opinion, it would be helpful to build a wasm target example in order to show the missing features and the current issues for this target. Just like the fantastic text-editor example which shows iced potential and how to interact with this library in a complete way.

This approach could help to:

  • Explain to develeopers how to implement something with wasm
  • Listen to the community requests and, if they are possible, adapt them to the example
  • Found issues and missing features

Just my 2 cents :smiley: