Feat-Req: Organize Beyond Depth 1

[tcardlab]

Really convenient and would love to use it more extensively, but the fact that collision detection is limited to immediate children is kind of limiting.

I'm not terribly familiar with Obsidians API, but here's my uneducated thoughts:

1. Select node who's children you want to deeply organize (usually Root) and use special hotkey to trigger action. Depth-first search to get deeply connected nodes (break/alert if cycle detected or ignore?). Sum height of children + gap heights (setting) to get chunk sizes, position/align chunks for each depth (given the initially selected node as the center line).
2. potentially take advantage of the group feature: a. if group has special name (some regex pattern), always deeply organize after updates (+/- node, node resized, connection changed, etc. ). b. use groups to limit scope of nodes you need to consider if that is troubling for any reason.

[shaunhurryup]

Thank you for the validation!

This diagram represents my comprehension of your concept. Are there any discrepancies?

[tcardlab]

That seems correct. However, I would like to note that this is just a simple 1 pass solution that guarantees things won't collide. It will work well for balanced/uniform graphs, but as they get larger the graph may skew and become harder to read.

Additionally, you may wish to calculate vertical alignment to distribute nodes vertically in a more aesthetic way:

• Identify the tallest layer. then for all layers, distribute chunks vertically based on that height (centered on the root/selected node).

Here are some examples of using this tallest layer method:

Centering & Spacing Given Max Layer Height:

Grouping Chunks For Weak Hierarchical Alignment:

Alternative:

The nature of organizing this uniformly is ultimately a 2-pass problem. So, if you want a more robust solution that maintains hierarchical alignment in non-uniform graphs with non-uniform node sizes, consider the following:

• First-Pass: for each layer (from terminal to root), sort chunks and calculate chunk heights progressively (terminal chunk is sum of node height(s) + gap, intermediate nodes are the sum of child chunks).
• Second-Pass: for each layer (from root to terminals), align chunks on parent and align nodes within each chunk (multiple ways to align nodes within each chunk).

As you can see, the parent height depends on the children and the child alignment depends on the parent height & position. This cyclic dependency points to the fact that two passes are needed to resolve this.

Example:

Given Some Tree Structure:

Align With 2-Passes:

Conclusion:

Organizing non-uniform trees is an opinionated task, which means someone is bound to be disappointed. The question now becomes, "what the least bad option?". I'll leave this for you to determine for your use-case.

[shaunhurryup]

Wow bro, sorry for the late reply, I'm being forced to learn rust language by my boss😂

You're really doing a lot of thinking ! Surely, the generation of nodes have different solution because we should consider many scenarios.

Tree structure and 2-Passes in the last example is a good choice, they will be released in the next version!