I’m wondering what is the use of the parameter of ValueTreeListener::valueTreeChildrenChanged(ValueTree & treeWhoseChildHasChanged)
Ideally, I would have understood if it was the actual child been passed on, but not the parent !?!
How to figure out the child then, if there is multiple children with the same type in the parent ?
I’ve tried valueTreeParentChanged, but it’s not called if it’s the parent, or am I missing something ?
Maybe it would be better to have valueTreeChildrenChanged(ValueTree & newChildren), after all, it’s easy to figure out the parent (getParent(), since it’s unique), but the reverse is not true.
In fact, I think this should be split in two : childrenAdded, and childrenRemoved (both with the child’s reference).
Looking at the code it’s not too difficult to do, since you have the child reference alive everytime while triggering the callback.
If you’re ok with this addition to the listener, let me know, I’d give it a shot.
I don’t really agree… In all my code I’ve never needed to know which child is being affected, I’ve always been more interested in the fact that the parent has had its child list changed in some way, whether than means something has been added, removed or just moved. I guess we have different approaches to the way we’re using these structures.
Well, I don’t think my use case is very exotic or anything.
I have a ContentComponent for the main window that owns the main document ValueTree (the one that’s serialized 1:1 to/from XML).
The content component use a tabbed component, with the first tab showing some of the value tree’s child (in a way).
When the user modify the data in this tab (like adding removing childrens), I want the content component to trigger and add /remove tabs for this specific new children.
I’ve registered the content component as a ValueTreeListener.
Currently, without the change I’m speaking about, I have to remember what was the state of the ValueTree before the change, (thus create a useless copy except for this), and then I have to compute a kind of diff to both tree.
I wonder how you can do it without such painful algorithm.
If you don’t need know what child was affected, it probably because you’re dealing with stateless change each time.
While it’s ok when creating/deleting a state has a small impact but it’s not in my case.
With this idea, every time there is a change, I’d have to delete all tabbed component, and all its children, unregister all Value listener for all tabs, and then recreate all the tabs for the existing children, recreate all components, recreate all Value listener, etc…
If I had the children that was changed, I would only deal with that children.
This is not possible, as it’s very distractful for the user, and it’s sluggish too.
Anyway, since what I’m asking doesn’t change the way the current code works, I think it’s worth it, so I’m going to implement this change, and submit it to you.
I’ve sent you a patch with this change. It’s lightweight, and doesn’t change any existing code (so it won’t break the current codebase), and yet, still add the missing functionnality for who want it.
