When you move one node, it often moves several other nodes in the process. I wish all other nodes would stay put while moving a node. Also, I wish the graph view didn’t reset every time I returned to it. I want the ability to save the placements of the nodes. Implementing both of these would help a lot in keeping pages organized.
Others also want to improve the data visualisation of the graph view however they have stated they’d like graph forces to organise their graphs: Improve Graph View: Relationship Types, Link Styling and Graph Parameters like in Cosma
perhaps your request could be implemented by implementing graph forces and saving the layout of the graph. This way you could turn off graph forces; reorganise the graph however you’d like, and then the graph could be saved for later.
There is a similar request: Predictable graph layout and journal nodes
The graph forces bit of this request has been resolved in the 0.10.6 release. The graph forces have been improved and you can customise them to your own requirements. This will not reset when you click away from the graph page, meaning that, by choosing graph forces that work for your graph, it should return to the neat layout
Also in the 0.10.6 release is the ability to freeze the graph (“pause simulation”) so that the rest of the nodes don’t move when you move one node. It will still however reset when you click away from the graph page.
logseq:master ← mp-v2:graph_forces
opened 05:28PM - 23 Dec 23 UTC
This MR adds the ability to change graph forces in the graph view, under a new d… ropdown menu item called "Forces"
This resolves requests for a customisable/better graph algorithm:
- https://discuss.logseq.com/t/extracting-more-understanding-from-graph-view-additional-graph-layout-algorithms/16841
- https://discuss.logseq.com/t/improve-graph-view-relationship-types-link-styling-and-graph-parameters-like-in-cosma/7023
- https://discuss.logseq.com/t/how-the-graph-view-could-improve-creativity/5579
This should also resolve some a number of user issues related to the graph layout being messy/not being very useful:
- https://discuss.logseq.com/t/graph-overlapping-problems/1726
- https://discuss.logseq.com/t/better-graph-make-sure-the-edges-of-graph-do-not-cross-like-obsidian/16862
Users resorted to manually dragging nodes to where they want them to be, and then requesting that the graph does not reset/re-render each time you click back to it. The ability to change graph forces means users can now customise the default force values, thus the default layout of their graph, using the config.edn default parameters. This indirectly resolves the requests to have a layout-persistant graph option:
- https://discuss.logseq.com/t/have-nodes-in-graph-view-stay-put-unless-moved/7942
- https://discuss.logseq.com/t/predictable-graph-layout-and-journal-nodes/3431
- https://discuss.logseq.com/t/ensuring-that-graphs-dont-revert-to-their-default-messy-state-when-i-click-away/3954/3
- https://discuss.logseq.com/t/persisting-graph-shape-keeping-nodes-position-after-navigating-away/3209
- https://discuss.logseq.com/t/is-it-possible-to-open-a-page-in-the-sidebar-from-the-graph-view/15283
To not overload the number of options, although more are possible using the same structure, I implemented the key ones:
- link distance _(The link force pushes linked nodes together or apart according to the desired link distance)_
- charge strength _(The many-body (or n-body) force applies mutually amongst all nodes. A positive value causes nodes to attract each other, similar to gravity, while a negative value causes nodes to repel each other, similar to electrostatic charge)_
- charge range _(The maximum distance between nodes over which this force is considered)_
The graph is reactive to the sliders, and the graph forces can be reset back to defaults using the "Reset forces" button, similar to "Reset graph" for the n-hops slider.
Force values, in general, default to the same value they were previously, so that the default experience is the same as it was before. Exceptions;
- link distance has been reduced from 180 to 70. This makes graphs significantly cleaner
- the velocity decay when dragging nodes has been reduced from 0.8 to 0.5 to allow the graph to better converge on a clean layout. This (partially) resolves issues like:
- https://discuss.logseq.com/t/better-graph-make-sure-the-edges-of-graph-do-not-cross-like-obsidian/16862
- https://discuss.logseq.com/t/how-the-graph-view-could-improve-creativity/5579/2?u=mapping_world
- https://discuss.logseq.com/t/graph-view-nodes-should-move-with-their-parents/1929
I set the sliders to have a stepsize proportional to the value size (e.g. 5, 10 or 100), to prevent too much rendering of large graphs. It would be more efficient to have the graph render on slider release (instead of on value change), however I would need someone more familiar with Clojure to assist with this.
Cheers,
mp-v2
Here is my personal graph using the master branch:
Here is the same graph with default forces in this branch (with lower velocity decay, allowing better convergence on a clean solution):
Now with adjusted forces based on personal preference. These changes are persistant, even when changing to note pages and returning to the graph view:
Examples from a large graph are much more exciting, but some examples below show options now available
Small link distance:
Large link distance:
Default negative charge (repulsion) changed to positive (gravity) causes orphan pages to come to the centre:
A positive charge strength, and long link distance, will group chuild nodes together from one node:
