# Graph View Wrapper for Plugins **URL:** \ **Category:** Feature requests\ **Tags:** graph-view, api\ **Created:** [February 4, 2024, 5:22pm UTC](https://forum.obsidian.md/t/graph-view-wrapper-for-plugins/76309 "2024-02-04T17:22:20Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Mutzu](https://forum.obsidian.md/user_avatar/forum.obsidian.md/mutzu/32/59643_2.png) [@Mutzu](https://forum.obsidian.md/u/Mutzu)\ **Post date:** [February 4, 2024, 5:22pm UTC](https://forum.obsidian.md/t/graph-view-wrapper-for-plugins/76309/1 "2024-02-04T17:22:20Z")
### Use case or problem I would like to add some features to the Graph View, but unfortunately there are only a limited number of ways to do this. > [@Show folders as areas in the graph](https://forum.obsidian.md/t/show-folders-as-areas-in-the-graph/8208/13): > > I was thinking about the Venn diagram dilemma that would happen when trying to visualize all notes and tags within folders. The solution could actually be quite simple: You leave the tags outside the folder areas. This would give them a graphical interface function. The following rules should suffice to customize the Graph View in this respect: Add a force that attracts notes from the same subfolder Add a force that repels tags from the folder scope Ensure that a subfolder stays within its … ### Proposed solution I read that the internals of the graph view are a bit convoluted. Maybe you could just provide something like a _wrapper_ with simple methods? Then you wouldn’t have to reorganize the code if you don’t want to… It might look something like this: ```typescript GraphView.Notes // All notes, that could be shown in the GV GraphView.Tags // All tags, that could be shown in the GV GraphView.Attachments // All attachments, that could be shown in the GV GraphView.Files // All files in the vault (Notes, Tags, Attachments, Orphan Files), that could be shown in the GV GraphView.Texts // All typographic elements GraphView.Connections // All connections between the Files, that could be shown in the GV GraphView.Elements // All visual elements (Texts, Connections, Files) GraphView.Forces // All physical forces ``` All visual elements of the graph may have these attributes: ```typescript Element.Forces // All physical forces that are applied on this element Element.physicsOn // true/false; Are the physical forces applied on this element? Element.visible // true/false; Is this element visible in the GV? ``` A Force object could have these methods, which could be overridden: ```typescript Force.apply(Element emitter, Element receiver) // This applies the Force originating from emitter on receiver. Force.getRadius(Element emitter) // This returns the effective radius of the Force originating from emitter. ``` Some fictional examples: ```typescript note.color = #FF3344; connection.label = "supports"; connection.thickness = 30; GraphView.Tags.hide(); // Hides all tags and all the connections attached to it GraphView.Tags.show(); // Shows all tags without the connections attached to it GraphView.Connections.show(); // Shows all the connections in the GV GraphView.Elements.add(triangle); // Adds a triangle element. triangle inherits from the class Element. GraphView.Tags.show(note); // Shows all tags that are connected to note GraphView.Connections.show(note, TAGS); // Shows all connections from note to its tags ``` #### Visual Memorability It’s helpful if you can always find your notes at almost the same place in the graph. To achieve this in a smooth, hybrid style, you might use these variables: ```typescript Node.x // Current X position of the node (for grabbing etc.) Node.y // Current Y position of the node (for grabbing etc.) Node.xCalc // Calculated X position of the node when the graph has reached its equilibrium (doesn't move anymore) Node.yCalc // Calculated Y position of the node when the graph has reached its equilibrium (doesn't move anymore) Node.xOffset // X position offset relative to xCalc when the user has moved the node to a new location Node.yOffset // Y position offset relative to yCalc when the user has moved the node to a new location Node.isPinned // true/false; the position of the Node (Node.x, Node.y) is pinned to it's current coordinates ``` When a new note/attachment is added to the graph, only as many other notes/attachments as necessary should move. For tags, it’s probably necessary to move pretty wildly to adapt to a new topology. #### Automatic scaling If there is too little space for the floating tag nodes, the whole graph might be scaled up, with the center of the graph as the scaling origin. If there is too much space between the notes/attachment nodes, the whole graph could be scaled down. `Node.x` and `Node.y` should follow this scaling, even if `Node.isPinned` is true. **This way the visual structure of the graph remains almost the same.** ### Current workaround Apparently, there seem to be some accessible methods like `findRenderer()` and `renderer.px.stage.addChild(text)`. Maybe they are enough for some additions. But if you want to add more sophisticated features or changes, I guess they won’t be sufficient. ### Related feature requests [https://forum.obsidian.md/t/api-for-writing-graph-related-plugins/815](https://forum.obsidian.md/t/api-for-writing-graph-related-plugins/815) [https://forum.obsidian.md/t/understanding-the-graph-view-core/41020](https://forum.obsidian.md/t/understanding-the-graph-view-core/41020) [https://forum.obsidian.md/t/any-plans-to-extend-the-api-to-allow-for-custom-graph-menus-or-changing-individual-nodes/62797](https://forum.obsidian.md/t/any-plans-to-extend-the-api-to-allow-for-custom-graph-menus-or-changing-individual-nodes/62797) [https://forum.obsidian.md/t/graph-link-types/74710](https://forum.obsidian.md/t/graph-link-types/74710)