Groot2 tree nodes model best practices

[schactus]

I've noticed that when you have a project with multiple subtrees in separate files that re-use the same node, the TreeNodesModel used by Groot2 is created in each of the subtree's xml files, as well as in your btproj file. To me this seems suboptimal for a few reasons:

1. Possible for TreeModels to get out of sync if developers make a mistake (our mistakes seem to be mostly version control related)
2. Need to fix any merge/rebase conflicts in several places if groot node models are changed
3. Hand editing the groot models (if working in an environment without access to a groot) requires changes in a lot of places
4. Generally undesireable to have duplicated information in codebase

To me, it would make sense if the TreeNodesModels were stored only in the btproj file - it seems reasonable to me that they would be separated out from the tree definitions, since they aren't actually required by the process that runs the behaviortree and therefore don't need to be loaded there, but maybe there's something I'm missing relating to attaching to a running tree in monitor mode.

Any recommended practices here? Is the duplicated TreeNodesModels expected, or is that an artifact of us incorrectly setting things up somehow?

[facontidavide]

To me, it would make sense if the TreeNodesModels were stored only in the btproj file - it seems reasonable to me that they would be separated out from the tree definitions, since they aren't actually required by the process that runs the behaviortree and therefore don't need to be loaded there, but maybe there's something I'm missing relating to attaching to a running tree in monitor mode.

If we do that, Groot2 will stop being able to open a single file, and it will be only able to open an entire project.
This seems to be a very annoying limitation.

Is the duplicated TreeNodesModels expected, or is that an artifact of us incorrectly setting things up somehow?

it is expected and desired (by me) for the reason above (each file should be self-contained).

Need to fix any merge/rebase conflicts in several places if groot node models are changed

This seems a weird statement. A model should reflect a C++ implementation. If it changes, in multiple places, it is because it MUST change.

Hand editing the groot models

Don't do it by hand :)

This problem of consistency happens only if you mix using Groot2 and editing by hand.

As you pointed out, BT.CPP itself doesn't require at all the TreeNodesModel, but Groot2 does.

My recommendation is to use Groot2 for editing and trust what it does.

Said that, I will be happy to add a feature in Groot2 to remove the TreeNodesModel from individual files, but I am sure that you will come back to me complaining that now you can't open those files anymore, because they don't have a model 😛

[schactus]

Point taken about having the files self contained - I can see why that's desirable.

This seems a weird statement. A model should reflect a C++ implementation. If it changes, in multiple places, it is because it MUST change.

To clarify this one, I'm talking about the case where 2 different developers on different branches add an additional port to a node. They must update the TreeNodesModel in Groot to match their change (expected), which modifies the TreeNodesModel definition in several files. When doing a rebase, there will then be conflicts that must be resolved (expected - conflicting changes cause conflicts). Rather than resolving the TreeNodesModel conflict in one place, they must resolve the same conflict in several places due to the duplication (suboptimal).

Said that, I will be happy to add a feature in Groot2 to remove the TreeNodesModel from individual files, but I am sure that you will come back to me complaining that now you can't open those files anymore, because they don't have a model 😛

I don't doubt that, but it may be a lesson I have to learn the hard way - the feature would be appreciated

My recommendation is to use Groot2 for editing and trust what it does.

This is probably the right answer