junxan
November 13, 2021, 7:43pm
1
In order to be able to use the graph view I would be great to be able to save graph layouts when they are modified by the user dragging nodes around. This would help to arrange nodes and clusters in ways that make it easier to remember.
It might even be possible to combine a animated force layout with a deterministic algorithm, these days for instance d3 uses a fixed seed to generate the same graph layout after reload.
Using d3 would also allow for instance to constrain the layout of journal dates in a straight line, so that pages and other nodes would lay themselves out along when they were journaled. Maybe using a weak link charge for page <-> date edges.
gww
December 5, 2022, 9:01pm
2
1 Like
I believe this is partially resolved by the 0.10.6 release. The graph forces have been improved and you can customise them to your own requirements. This should mean the graph layout it defaults to is not messy, as you can customise the forces used. These are persistent when you click away and return to 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"
![image](https://github.com/logseq/logseq/assets/16655368/ff2a04e4-435b-41a0-8a6b-e1c73a58e0ac)
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)_
![image](https://github.com/logseq/logseq/assets/16655368/100ac2d6-722b-4b28-b8c2-ef131f94e510)
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:
![image](https://github.com/logseq/logseq/assets/16655368/a2be7fe2-5e81-448b-98f0-b77065fad3ef)
Here is the same graph with default forces in this branch (with lower velocity decay, allowing better convergence on a clean solution):
![image](https://github.com/logseq/logseq/assets/16655368/2a20f9d6-8fa9-4aee-a42d-a170cb9ad766)
Now with adjusted forces based on personal preference. These changes are persistant, even when changing to note pages and returning to the graph view:
![image](https://github.com/logseq/logseq/assets/16655368/e1339161-91da-4ab6-b544-b41f0f464d1a)
Examples from a large graph are much more exciting, but some examples below show options now available
Small link distance:
![image](https://github.com/logseq/logseq/assets/16655368/c4c96ac5-3cab-41c5-96c8-45ec17332353)
Large link distance:
![image](https://github.com/logseq/logseq/assets/16655368/0e35b7a9-da41-4d90-aefc-e4b1649f462d)
Default negative charge (repulsion) changed to positive (gravity) causes orphan pages to come to the centre:
![image](https://github.com/logseq/logseq/assets/16655368/cdc0c314-51c8-407b-bccc-e1551f50c1a3)
A positive charge strength, and long link distance, will group chuild nodes together from one node:
![image](https://github.com/logseq/logseq/assets/16655368/a8dcd853-c8a3-4f7f-b9b5-f62f35959c7a)