Highlight parent and child connections of selected node in Tree

[boukew99]

Describe the project you are working on

A small drawing app

Describe the problem or limitation you are having in your project

When there is a big nested SceneTree, it can be hard to see what the parent child connections are (especially after scrolling). Right now I solve it by collapsing to get a better overview. Then I can reorganize the SceneTree by drag and dropping nodes under the right parents.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

A simple highlight of the parent child connections can overcome this problem.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

If this enhancement will not be used often, can it be worked around with a few lines of script?

It is editor, so no?

Is there a reason why this should be core and not an add-on in the asset library?

IMO it adds more visual clarity to Tree (SceneTree and FileSystem), which is beneficial to all users.

[Calinou]

This is a pretty cool idea – I've never thought about it before. Unfortunately, I'm not sure if Tree implements what is needed. The Tree class is pretty complex as it is already, and adding more functionality that will be used just in the editor may be overkill.

I guess we could draw over some lines directly in the editor Scene tree dock code if we don't want to make the Tree class even more complex. That said, this would likely be more hacky.

[mathias17]

I love this idea!
I'm not sure about the exact visual end-result, but your mockup looks great and is certainly a nice starting point.

In my opinion, the scene tree panel can get pretty confusing in complex scenes. I find myself collapsing parent nodes just to make sure I'm correctly discerning which nodes are its children or siblings. It consumes valuable time.

Scene tree panel ui clarity improvement on par with the new Inspector ui improvement could make a world of difference.

To not implement something like this feels like an obvious lost opportunity.

[boukew99]

I assume you mean the class is complex from a user perspective (or as engine dev?). If so, then maybe an idea to split the Tree Class as it seems to be composed of multiple functionalities.

A BranchContainer seems like one of those functionalities to me. Mostly similar to VBoxContainer, but with child lines, indent and collapse functionality. A tree would then just exists out of many BranchContainers.

How it would look in editor

The "result" with the collapse and indent rectangles (red)

And coming back to the highlight, the BranchContainer could then have a highlight_connections property, which would then only highlight child connections (since those are there in any case there). The parent connection is then omitted, but I think that is okay.

Then there are some functionalities still left of the Tree Class, but that is beyond the scope of this issue, so I will just leave it at this for now.

I don't know if BranchContainer is useful implementation wise, but it would be pretty simple to make a basic Tree in the SceneTree.

[mathias17]

So in your initial mockup image only the currently selected node's child connection lines have changed colors; the color change only happens for selected node.

Idea: What about a color change on hover as well?
Would it help if child connection lines also changed as you moved your mouse up and down the tree view? A less bright highlight color so the currently selected node's children are still clearly indicated.
(Similar to a website button having a rollover/hover effect - feedback without needing to click.)

[boukew99]

I think that would be too distracting, since you do not need to know the child connections every time you hover over something.

[mathias17]

It's probably too much. I think you're right.

[mathias17]

Since ui changes like this affect everyone it may be best for them to have toggles in Editor Settings so they can be turned off/on at will.

[dalexeev]

I don't like this idea. It's too complicated and not universal. For example, one node can have many signals connected to methods of different scripts (different nodes). That is, even if we highlight the connections of only the currently selected node, the lines can overlap each other (and even give the impression that there is only one line). And even if the lines do not overlap, their presence does not give you the knowledge of which signal which node is connected to.

[boukew99]

I did not mean signals, just highlighting who the parents and who the children.

[mathias17]

I don't like this idea. It's too complicated and not universal. For example, one node can have many signals connected to methods of different scripts (different nodes). That is, even if we highlight the connections of only the currently selected node, the lines can overlap each other (and even give the impression that there is only one line). And even if the lines do not overlap, their presence does not give you the knowledge of which signal which node is connected to.

I agree - adding more connector lines to indicate signal relationships is a bad idea, for the reasons you described.

But this proposal isn't suggesting that. This idea entails merely changing the color of existing connector lines in the tree view based on whether they're a child/parent of the currently selected node.

(Again - probably wise if this was an optional setting so those opposed to the actual idea could simply leave it off.)

[dalexeev]

I apologize, I didn't read the first post carefully, and I got the wrong impression that we are talking about signal connections.

The suggestion to highlight the branch of the currently selected node is harmless enough, and I don't mind it as long as this behavior is configurable. But I'm not sure that it makes sense to highlight the children of the current node and sibling nodes, as on the mock-up, since it can be confusing.

[dalexeev]

This is how I imagine it:

Editor Settings:

• Highlight ancestors
• Highlight descendants
  • Only children

And I chose a less distinctive color so that it was clear that this is just usability and does not have any special meaning.

[mathias17]

Nice. Less distinctive color makes a lot of sense.

Good nomenclature, too -
Is this correct? :
Ancestor = parent and all parents of direct parent
Descendent = children and all children of children

Speaking of colors, though - each different relationship type could have its own ui theme color slot.
This way users could choose a different color for ancestors and descendants. All optional of course!

[YuriSizov]

Less distinctive color makes a lot of sense.

I'm not sure. When I first saw this proposal I didn't even notice anything on the screenshots in the OP. It took me a couple of seconds of searching for details to realize the lines were highlighted. So I'm not sure they are that much in the face to begin with. That said, color is not our only tool, theoretically. Thickness and shape can also be considered, at the very least.

Also I like the idea of parent and children lines being highlighted differently.

[dalexeev]

Less distinctive color makes a lot of sense.

I'm not sure. When I first saw this proposal I didn't even notice anything on the screenshots in the OP.

When switching between nodes, this will be noticeable enough. The eyes are good at distinguishing changes over time, even if the difference is not visible in the static picture.

[YuriSizov]

@dalexeev Fair enough. I want to make a prototype to see how it behaves anyway. Maybe it will give us a better idea how much accent to put onto these lines.

[YuriSizov]

Okay, after some playing around with it I think that:

• Relationship lines should keep their color and only need to adjust opacity/contrast. Accent color here is way too pronounced and distracting. We can work with the opacity, since the base opacity is already a setting that is exposed. In my example I ended up shifting opacity by an arbitrary value from the base one. More so for the parent line, less for child lines.
• I propose that parent line is a bit thicker than default and child lines. I think it allows to subconsciously notice that those are different types of relationships. And we can't make child lines thicker, because there will be way more of them, it will become annoying. Some trees also have items selected by default, like the FileSystem dock, so it would just have yelling big lines if we make child lines thicker. Therefore, it's better to do this to parent lines.
• It makes most sense to highlight all the parents, but only direct children. I'm not sure it's worth adding more options (except for maybe disabling this completely). That is if we are talking about improving editor's trees. If there is some desire to have it more customizable for user projects, we can allow for more options here. But I don't think we need this for the editor, which is what I think the conversation was about.

Here's an example of this in action. Don't mind that lines look a bit weird, there are small problems with them being semi-transparent which I didn't bother addressing for a proof of concept.

2021-05-02_18-25-20.mp4

---

On a side note, breadcrumbs can be useful to help show the depth of individual selected nodes. Many code editors employ such UI, and also tools dealing with XML/HTML such as browser dev tools. This is what I mean:

Something like this can be shown above the tree in the Scene dock.

[boukew99]

Nice! Did you try only thickening the direct parent node of the selected node and then the parents above that with a normal thickness? Think it might look a bit more balanced.
*edit: nvm

[YuriSizov]

@boukew99 Sorry, no, but I think it won't look much different than if we don't highlight further parents at all. Check out the PR, I've improved the looks more for the final version. Hope you like it 🙂

[boukew99]

Okay :), just kinda wanted to experiment with it myself, but don't know how. Excited to try it out!