Graph Editor Architecture

[teodosin]

Tracking issue and summary for determining the proper architecture for the graph entity crate. The goal is to separate this into a standalone crate that can be used by any bevy project.

---

• Make ui reactive to the underlying data entities Make ui module reactive to graph changes #65

• Group all relevant files and submodules under a single module Group graph modules under a single crate #73

• Move forces to bevy_overlay_graph

• Separate data and view nodes into their own entities Separate the data and view of nodes into their own entities #67

• Clarify and clean up dependencies (must not be dependent on Karta, Karta depending on BOG is ok)

• Component property panel (blocked by UI Node base implementation #66)

• ?

• bevy_overlay_crate git submodule

• bevy_overlay_crate public, usable through github

• 0.1 on crates.io

Resources

• https://www.howtogeek.com/devops/how-to-turn-a-turn-a-directory-in-a-git-repository-into-a-submodule/
• https://doc.rust-lang.org/cargo/guide/

[teodosin]

Initial thoughts:
#48 Seems like a good aspirational goal. If Karta is eventually meant to appeal to programmers or writers, it would make sense that the entire UI / App would have support for keyboard only. Traditional keyboard shortcuts with the modifier keys as well as a vim-mode for those who don't want to move their hands from the home row. This could be under a feature flag.

Touch and stylus support would also be a feature. Also down the line: Vr controller and glove support. But that's not for at least a year or two or three.

One thing that needs to be decided now is whether the graph view nodes should remain as separate entities from the data they contain. I'm thinking yes. A graph node should only contain the data necessary to draw itself and interact with the graph. What happens in the scene (#49) should be a separate set of entities that work stand-alone even without the graph editor plugin.

A graph view node entity is always spawned when its data counterpart is also spawned. It may be turned invisible, but it is there. It may remain spawned after its data is despawned if it is pinned to presence. It would be nice to make it so the ui reacts automatically to the Scene World so that the Scene World doesn't have to know about the graph. The graph could be used to insert systems and logic into the Scene World but the Scene World itself doesn't have to know about the graph. This I think is a requirement for any kind of use as a Bevy game editor.

Graph view nodes should generate their preview and the cache it. They shouldn't keep their relevant files loaded. The scene will be in charge of that, if those Assets are needed by it.

An immediate change that should be made is the restructuring of context.rs. The update_context function should be split up into marking the despawnable nodes, the spawning of an individual node (the root) spawning the context of that node. Something like that. Both the spawn and despawn functions optionally take in a filter as an input to select which nodes to despawn and which ones to spawn from a context.

[teodosin]

How would this work as a crate that could be added to any bevy project?

Visualise entities and their relationships as well as system schedules, resources, and events.

Karta would then be an app that merely uses the graph crate to visualise itself. It would just manage the database of node networks, spawn nodes as entities and the graph representation would be generated by the graph crate just like for any other bevy app.

I personally still need a much deeper understanding of Bevy in order to make this work. I'm not clear on the separation between Karta's features and those that should belong in the crate. There might also need to be ergonomic ways to define custom node types, context menu actions and such on a per-app basis. And all this needs to play well with Karta's own scene system.

Not in scope of the thesis, I don't think.

[teodosin]

The context menu for the graph editor obviously needs to be defined inside the crate. Users of the crate should be then able to add their own actions to the menu. How should this be implemented? With a trait? A method that modifies some resource? How would this play nicely with the ECS?

What if context menu actions could be defined per-component? Intuitively that feels powerful. Then users could impl the trait on the components that they want to add context menu actions to. Hmmmm

[teodosin]

https://github.com/teodosin/bevy_overlay_graph

In preparation.

[teodosin]

Another important thing that needs to be iterated on is how to separate the inputs of the underlying Bevy app and the graph crate. The graph is an application by itself with navigation and menus and such, but it should not interfere with the user's app inputs. There needs to be some kind of toggle that is able to disable the user's inputs to their own app from within the crate. At least that would be most ergonomic, so the user wouldn't have to manually make sure to disable their app inputs when they want to navigate the overlay.

So far this feels like the biggest hurdle in making this usable as a crate.

[teodosin]

Sunday project: https://github.com/teodosin/bevy_overlay_graph now exists. It works; it spawns nodes for each entity with the GraphEntity component and displays their Name component on the node label. There's a lot of work to do there to reach feature parity with Karta's current build but without all the coupling.

I'm working on that crate in a separate workspace and using a dummy Bevy project to test it. I think that's a better path than refactoring and creating the crate while still inside Karta. This way I can build the crate to support what Karta needs without breaking Karta. Then when there's feature parity, Karta can be refactored to use the crate's API.

[teodosin]

Cleaning up some issues. Most of the work has been done in now deprecated repos which have been merged into this monorepo.