Hey, as others have pointed out, for the first problem you can use getters and setters in your trait to pull in data from the structs that implement it. I find this a bit cumbersome also and wish I could somehow make the underlying data also part of the trait (required in the struct in order to implement the trait — or when you implement the trait you specify the data mapping right there), or even better have some mechanism similar to python properties. Having said this, if you find yourself wanting to add a lot of getters/setters to a trait to pull in data from the struct, that’s probably a strong indication you need to refactor and split the code into separate traits. This is Rust telling you to rethink and re-engineer the problem. Embrace the challenge — and your code will likely end up faster and better designed as a result. That is my experience so far.

For the GUI cyclic tree issues, I also think this is an indication to rethink the problem and approach it differently in a more Rust-appropriate way. Similar to other suggestions, I recommend storing all of your state in a central structure (i.e. think Redux) and in your widgets themselves you only need to store the indexes of the parent widget and children etc. Whenever you need to do operations where one widget needs to interact with its parent, you can either do that via the object that holds the state or otherwise pass in the relevant widgets specifically for the interaction in a way where the borrow is contained only within 1 function.

In general when I hit issues with the borrow checker I start thinking in terms of data/memory and whether I can get by with just 1 copy of the data or whether I should clone and pass a second copy around. Quite often if you want to get by with just 1 copy of some data, it should be owned by one struct, and referred to elsewhere by index or strictly as-needed (temporary borrow only). Hope this helps…