Add an optional minimap to GraphEdit

[YuriSizov]

Describe the project you are working on:
Editor tools for my game with a logic graph.

Describe the problem or limitation you are having in your project:
Working with a large enough graph can be a challenge, as you can get lost between different nodes. Zooming out is an option, but it's not really that handy or fast. Plus, at zoom levels other than default text can look ugly and unreadable due to scaling. So it's not really possible to work at those zoom levels permanently.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
An overview in a form of a minimap can be used to make GraphEdit more accessible with larger graphs. It gives a user a complete look at the graph with immediate feedback on their actions and provides a quick navigation option.

Here is an example I've made in GDScript:

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
There are several problems that need to be solved along the way, but in concept it should work like this:

• GraphEdit has one more child, a Panel, that is semi-transparent;
• Position of this panel can be configurable to anchor to any angle, it can also support resizing;
• This panel receives information about all the nodes and connections present on the parent graph;
• Assuming the panel must render a complete map, its dimensions are used to scale actual node coordinates to the minimap ones;
• Nodes are represented by a small circle or square, color of which must be approximated from the node's style, or manually provided by user, who created it;
• Connections function the same as on the parent graph, though their Bezier settings must be adjusted to a smaller scale;
• Minimap is updated in real time, with every node added, removed, or moved, and after each connection or disconnection.

Not shown in the image above is a rectangle representing "camera", or rather offset of GraphEdit. Additionally, clicks on the minimap should move the offset to the location corresponding to the click.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It can be created with a script, at least partially. However, similar to code editor minimap some built-in graph editors (Visual Script, Visual Shader) can benefit from it as an option. And the implementation feels like a natural extension of the GraphEdit itself, so making it part of the engine allows everyone to rely on it and use in their own projects.

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

P.S.: I can work on this myself.

[fire]

I can code review your plan.

Can you post design mockups of the ui?

How will you treat comment groups?

Edited for more details.

[YuriSizov]

@fire

Can you post design mockups of the ui?

Is the image in OP not enough? It's unfinished, as I keep working on it in my GDScript implementation still, but the idea is as shown. I think that the visibility of the minimap can be controlled by a new button in the top HBox of the GraphEdit, similar to how grid is toggled.

How will you treat comment groups?

That I have to look into, as I've not used them. Do you have any suggestions or concerns?

[fire]

Using this as your mockup...

How do I know what color is what?

Color blindness is a factor, will probably need to use shapes.

[YuriSizov]

Colors are associated with colors of GraphNodes themselves. Obviously, not everybody uses colored nodes and extracting a correct and representing color may be non-trivial. But shapes... Shapes cannot be taken from anywhere.

Which is why I've pointed out that maybe GraphNodes should receive a new setting for associated minimap color (or icon/shape). This way everybody can customize their look to be comfortable for them. By default we can still rely on color and try to approximate it given any information we have handy. In the worst case, just use contrast colors to what the theme is.

[fire]

Do not like customization taking place of defaults.

I mean use one type of shape for each type. Like green will be diamond, yellow will be square, purple will be hexagon, etc.

[YuriSizov]

Well, inferring a shape from a color can certainly be an option, but I'm not sure how well can that scale. Even circles can look distorted at that size.

I also don't understand at all what do you mean by this:

Do not like customization taking place of defaults.

You don't appreciate having a setting for minimap representation of the node, that is user accessible? For things like visual scripting and visual shader it won't be exposed, it would be configured in engine, where the nodes are defined.

[fire]

Do not like customization taking place of defaults.

Having a minimap representation of the node that is usable need[s] to be exposed, but that is not an excuse for not choosing what it looks like for the people who don't modify their settings.

For the color issue, all I'm saying is that the color on the nodes are effectively meaningless because of color blindness and etc issues.

http://gameaccessibilityguidelines.com/ensure-no-essential-information-is-conveyed-by-a-colour-alone/

Edited:

The existing text preview uses the shape of the paragraphs.

[YuriSizov]

For the color issue, all I'm saying is that the color on the nodes are effectively meaningless because of color blindness and etc issues.

Color is not the essential part of my proposal. It does not come with it. All I do here is use the color that is already present on the graph: if a node is colored on the graph, it is colored on the map. By default the white color is used for nodes. Connections have color settings that can be easily extracted from slots, so for them those colors are used.

A minimap is going to help by its sheer existence alone, colorful or not. It's going to give a user a representation of the whole graph at a glance. Nodes and connections already tell a story to someone who works with the graph. With navigation by clicking the minimap anybody can quickly check any part of the graph.

Shapes, however, are arbitrary. Which is why I'd rather leave it to the user (who creates the control node) to set them up. For example, if someone is using graph node for a flow chart, they'd want to have shapes familiar from other flow charts. Doing arbitrary stars, rectangles, etc. based on color alone is going to be confusing for them.

The feature you are asking for can be implemented, but I'm not going to assume what is comfortable for a colorblind person in this particular case. In the end, some random shapes can be enabled and enforced from some accessibility option in editor settings, unless overridden by the GraphNode settings, but I have no idea how exactly it must work for it to be usable.

But I'd like to repeat, that with current proposal (and my internal GDScript implementation) the minimap is as usable for a colorblind person as the graph itself is. Going extra mile is good, but I have no idea where to go with that.

How will you treat comment groups?

I've played around with them a bit, though to be honest, I don't really understand their purpose. It seems that they can be used for an underlying layer to provide some visual grouping for other, normal nodes. As such, I suggest depicting them as a frame, corresponding to the comment's size and position.

Here's some of my experimentation:

Those 4 blue nodes close together have a comment node underneath them. The other, lighter frame is "camera" viewport representation.