Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Currently, the UI is very tightly coupled with the underlying implementation of
GodotProject. The UI is directly responsible for control and sometimes syncing logic. Not good!This means any extraneous UI refreshes come with a backend performance penalty.
Instead, this PR encapsulates GDScript-visible APIs as much as possible, and moves as much core functionality to Rust as possible.
API Architecture
As such, a new file
godot_project_api.rsdefines a trait (name negotiable):The
GodotProjectViewModelprovides a Rust API that any UI can communicate with, to do atomic (or as atomic-as-possible) user interactions on the project.GodotProjectexactly wraps this Rust API, converting everything to Godot-compatible data. (Unfortunately I don't think#[godot_api]supports custom traits, or I'd make that one into a trait too, to ensure API agreement).String ID deprecation
Also in this PR, I'm phasing out usage of
Stringin lieu of ex.DocumentIdandChangeHashacross the codebase. That way, parameters are converted to and from aStringwhen absolutely necessary (i.e. when we're talking to the UI) but most of the time they use the more type-safe (and much faster) version.Change Caching
Another important piece: changes are now cached per update. Rather than the UI calling the expensive
get_changes()directly,GodotProjectImplcan simplyingest_changes()whenever it thinks there are new changes to ingest, and notify the UI to refresh.As a result, we no longer have to worry about efficiency on the UI side: we can just call Rust methods whenever we need data to display.
Async/Await
Much of the UI code has been refactored, so I removed a lot of the old callback approach and added await.
User-Facing Changes
While the focus of this PR isn't to edit any functionality, some has been altered for clarity or simplicity:
To-Do
To get this PR out of draft...