Add func (*TreeNode) GetParent

[paololazzari]

Being able to get the parent of a given node would make traversing the tree much easier

[rivo]

Can you give some details how this would help you in your specific application? There is Walk() which is a public function, which also gives you parent information for each traversed node.

[paololazzari]

@rivo I have something similar to the demo here https://github.com/rivo/tview/tree/master/demos/treeview . When I press enter and a node which corresponds to a valid file is selected, I want to open that file in a textview. Opening the file for files within folders requires having the name of the parent nodes too

[rivo]

Isn't your actual requirement then to get the entire path to the current node, not just to the parent? Like the breadcrumbs you see on many websites?

If so, a better solution would then be to provide a GetPath(node *TreeNode) []*TreeNode method which gives you all nodes leading to your current node, starting at the root.

What do you think?

[paololazzari]

Yes, absolutely!

[paololazzari]

Actually, this seems to be simple enough already. As long as the reference is set to the full path (as shown here then its trivial to get the full path of the selected node with GetCurrentNode().GetReference().(string)

[rivo]

Well, I added the function (check out the latest commit) while I was travelling and offline so I only saw your message afterwards. But you are right, in the demo, the full path is stored as a reference object so it's available anyway.

[digitallyserviced]

@paololazzari

Just my $1.39...

As far as being able to get the parent of a tree's node, I agree with @rivo in that this is not something you should be reliant upon due to the transient nature the parent of a given leaf node is.

While it may seem odd that parent is temporary, or should not be relied upon for what you are attempting is the fact that the parent/root node of a tree, can change all the time.

Also if you try and rely on what should only be GUI/view objects, for handling the representation of an underlying tree/graph such as a filesystem or hierarchy, you're gonna have a bad time. If you are going to actually try using it to determine the state/position of the actual data structure represented, you will run into problems.

The fact is that the tree's View/GUI/Nodes/Leafs/Left Leg/Religion can be refreshed/re-rendered accurately at any time from the tree/graph it represents.

The same really is not true for the opposite.

The root node can be changed at any time, and a child can become the new root, freeing the previous root/parents from memory and visibility. Usually its not even feasible to show a whole tree root to branch due to numbers of items.

If the parent references are not temporary and the link/refs to parents not ini view anymore, you will run into memory issues as they wont be GC'd

Temporary nodes or indicators for things not actually yet in the underlying data such as future, in-process, possible changes.

What if nodes are multi parented? representing the same item but that could be linked/avail in other places, but always the same item. Pretty much any operations that you may want to represent in the View of a tree/graph should be just that, a representation, and not some hologram of accurate data from the backing tree/nodes/graph.

Keep the tree/graph/node structure in a separate data struct, and use the SetReference of a TreeNode for gettinng references to whatever it, well, referencecs...

Also keep a reference from the referenced node, to your tree's node/leaf item.

This is actually a tree file browser/view that I have utilized in my own apps.

It handles it nicely and also has a fix for the reprocessing of the tree you may not have run into a problem or handle yet.

It is a bit more involved than you may deem neccessary, but I believe a lot is neccessary to save you from headaches in future.. have i steered you wrong yet?

https://github.com/josa42/term-finder/blob/738831e1825d7588dd1f003a10dcac1ee9d4c75e/tree/fsnode.go#L19