fork/Graphite
1
0
Fork 0
mirror of https://github.com/GraphiteEditor/Graphite.git synced 2026-09-23 17:48:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

Add the new AI contribution policy

Browse Source
This commit is contained in:
Keavon Chambers
2026-01-05 17:03:42 -08:00
parent 2a59bd50bd
commit 4f4ec7ffff
10 changed files with 94 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
website/content/volunteer/guide/codebase-overview/debugging-tips.md
+3 -5
View File
@@ -9,7 +9,7 @@ The Wasm-based editor has some unique limitations about how you are able to debu
## Comparing with deployed builds
When tracking down a bug, first check if the issue you are noticing also exists in `master` or just your branch. Open up [dev.graphite.art](https://dev.graphite.art) which always deploys the lastest commit, compared to [editor.graphite.art](https://editor.graphite.art) which is manually deployed from time to time for the sake of stability.
When tracking down a bug, first check if the issue you are noticing also exists in `master` or just in your branch. Open up [dev.graphite.art](https://dev.graphite.art) which always deploys the lastest commit, as opposed to [editor.graphite.art](https://editor.graphite.art) which deploys the latest stable release. Build links for any commit may be found by clicking the "comment" icon on the right side of any commit in the [GitHub repo commits list](https://github.com/GraphiteEditor/Graphite/commits/master/).
Use *Help* > *About Graphite* in the editor to view any build's Git commit hash.
@@ -19,13 +19,11 @@ Beware of one potential pitfall: all deploys and build links are built with rele
Use the browser console (<kbd>F12</kbd>) to check for warnings and errors. Use the Rust macro `debug!("The number is {}", some_number);` to print to the browser console. These statements should be for temporary debugging. Remove them before your code is reviewed. Print-based debugging is necessary because breakpoints are not supported in WebAssembly.
Additional print statements are available that *should* be committed.
Additional print statements are available that *should* be committed:
- `error!()` is for descriptive user-facing error messages arising from a bug
- `warn!()` is for non-critical problems that likely indicate a bug somewhere
- `trace!()` is for verbose logs of ordinary internal activity, hidden by default
To show `trace!()` logs, activate *Help* > *Debug: Print Trace Logs*.
- `trace!()` is for verbose logs of ordinary internal activity, hidden by default but viewable by activating *Help* > *Debug: Print Trace Logs*
## Message system logs
website/content/volunteer/guide/codebase-overview/editor-structure.md
+4 -4
View File
@@ -7,7 +7,7 @@ css = ["/page/developer-guide-editor-structure.css"]
js = ["/js/developer-guide-editor-structure.js"]
+++
The Graphite editor is the application users interact with to create documents. Its code is one Rust crate sandwiched between the frontend and Graphene, the node-based graphics engine. The main business logic of all visual editing is handled by the editor backend. When running in the browser, it is compiled to WebAssembly and passes messages to the frontend.
The Graphite editor is the application users interact with to create documents. Its code is a single Rust crate that lives below the frontend (web code) and above [Graphene](../../graphene) (the node-based graphics engine). The main business logic of all visual editing is handled by the editor backend. When running in the browser, it is compiled to WebAssembly and passes messages to the frontend.
## Message system
@@ -43,11 +43,11 @@ Click to explore the outline of the editor subsystem hierarchy which forms the s
## How messages work
Messages are enum variants that are dispatched to perform some intended activity within their respective message handlers. Here are two <span class="subsystem">DocumentMessage</span> definitions:
Messages are enum variants that are dispatched to perform some intended activity within their respective message handlers. Here are two message definitions from <span class="subsystem">DocumentMessage</span>:
```rs
pub enum DocumentMessage {
...
// A message that carries one named data field
// A message that carries one data field
DeleteLayer {
id: NodeId,
}
@@ -57,7 +57,7 @@ pub enum DocumentMessage {
}
```
As shown above, additional data fields can be included with each message. But as a special case denoted by the <span class="submessage">#[child]</span> attribute, that data can also be a sub-message enum, which enables hierarchical nesting of message handler subsystems.
As shown above, additional data fields can be included with each message. But as a special case denoted by a <span class="submessage">#[child]</span> attribute, that data can also be a sub-message enum, which enables hierarchical nesting of message handler subsystems.
By convention, regular data must be written as struct-style named fields (shown above), while a sub-message enum must be written as a tuple/newtype-style field (shown below). The <span class="subsystem">DocumentMessage</span> enum of the previous example is defined as a child of <span class="subsystem">PortfolioMessage</span> which wraps it like this: