You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Overall the experience was fantastic and this crate made the whole thing possible. Thank you for creating it!
Here are some random feedback notes I gathered, if that helps, I can create individual issues or convert this to a discussion instead:
Snarl::get_node() and Snarl::get_node_mut() panic if the passed index is invalid: at runtime I can handle this by keeping good data but loading old serialized states would sometimes trigger this due to code changes. It would be helpful to return an Option<T> here.
There is no way for my app to query the state (pins) of other nodes without keeping track internally
There are several unused functions on Viewer
It would help if nodes had some "body" area other than the header (or dummy inputs/outputs): for UI related to that node
Connecting wires to the nodes is sometimes buggy and switches to drag/pan mode or just drops the wire
Node indexes as usize values feels a little raw; opaque NodeHandle instances which derive the same traits would make the API clearer
The "node based" approach of this library is different from other similar crates and made it very easy to get started
The text was updated successfully, but these errors were encountered:
Thank you for you feedback. It is extremely valuable!
First I'd need to ask if you used released version or HEAD from repo? From your description I guess you've used the repo version.
Since release I changed approach a bit to use more indices instead of RefCells, since in complex scenario RefCells are harder to use then simply indexing nodes from Snarl on spot.
Using handle for node is possible, but no reason making it opaque, just transparent wrapper to not index Snarl by some unrelated usize accidentally.
The node will have 5 areas in the final design.
____________________________
| HEADER |
|--------------------------|
| IN | BODY | OUT |
| PINS | | PINS |
|--------------------------|
| FOOTER |
|__________________________|
All will optional. Except, probably, HEADER.
The BODY part would be actually least used I guess.
Some large part of the node UI could be placed in FOOTER, like images here.
Another option will be showing tooltip for pins.
For example I'm making GPU WorkGraph editable with egui-snarl and want to show intermediate images in pin tooltips on hover.
If dragging new wire from pin drops it means that egui decided that dragging stopped, and maybe started again from graph background (which does panning).
Personally had no such experience. You can try to log mouse button events to see if release event is fired when you have this issue.
👋 Hello! I saw this library on the egui discord and thought I would try it out with an idea I wanted to test.
I created an editor for node graphs used by the noise crate:
https://github.com/attackgoat/noise_gui
(web demo here)
Overall the experience was fantastic and this crate made the whole thing possible. Thank you for creating it!
Here are some random feedback notes I gathered, if that helps, I can create individual issues or convert this to a discussion instead:
Snarl::get_node()
andSnarl::get_node_mut()
panic if the passed index is invalid: at runtime I can handle this by keeping good data but loading old serialized states would sometimes trigger this due to code changes. It would be helpful to return anOption<T>
here.There is no way for my app to query the state (pins) of other nodes without keeping track internallyViewer
usize
values feels a little raw; opaqueNodeHandle
instances which derive the same traits would make the API clearerThe text was updated successfully, but these errors were encountered: