Revamp the Graphite website (#1265)

Revamp the website with more content
2026-10-07 04:08:13 +08:00 · 2023-08-10 18:37:04 -07:00
parent f2b0abc164
commit f429db6369
76 changed files with 3506 additions and 1670 deletions
@@ -0,0 +1,70 @@
+++
+title = "Volunteer"
+
+[extra]
+css = ["/volunteer.css"]
+++
+
+<section class="section-row">
+<div class="section">
+
+# Volunteer
+
+Graphite is built by volunteers. Join the effort to bring great, free creative software to the world.
+
+</div>
+</section>
+
+<section class="section-row">
+
+<div class="diptych">
+
+<div class="section creative-contributions">
+
+## Creative contributions
+
+<a href="https://discord.graphite.rs" class="button arrow">Ask how to begin (Discord)</a>
+
+<div class="info-box">
+
+### ART TEAM
+
+Use your artistic talents to plan and produce ambitious open art projects published by the Graphite project to stress-test and showcase the editor's capabilities.
+
+</div>
+<div class="info-box">
+
+### PUBLICITY TEAM
+
+Become the author of feature announcements, [blog](/blog) posts, website content, the user manual, press releases, social media posts, and industry outreach.
+<!-- Become the author of feature announcements, [blog](/blog) posts, website content, the [user manual](/learn), press releases, social media posts, and industry outreach. -->
+
+</div>
+
+</div>
+<div class="section code-contributions">
+
+## Code contributions
+
+<a href="/volunteer/guide" class="button arrow">Contributor guide</a>
+
+<div class="info-box">
+
+### EDITOR TEAM
+
+Write code to build and maintain the Graphite editor itself, ranging from the Svelte/TypeScript frontend UI to the tooling business logic written in Rust.
+
+</div>
+<div class="info-box">
+
+### GRAPHENE TEAM
+
+Develop the core engine that powers Graphite's node graph and rendering. Graphene is a programming language, compiler, and distributed runtime ecosystem built upon Rust.
+
+</div>
+
+</div>
+
+</div>
+
+</section>
@@ -0,0 +1,11 @@
+++
+title = "Contributor guide"
+template = "book.html"
+page_template = "book.html"
+aliases = ["/contribute"]
+
+[extra]
+book = true
+++
+
+We're glad that you are interested in contributing to Graphite! We want to make it as easy and frictionless as possible for you to get started. Here are the basics.
@@ -0,0 +1,67 @@
+++
+title = "Codebase overview"
+template = "book.html"
+page_template = "book.html"
+
+[extra]
+order = 2 # Chapter number
+++
+
+<div class="video-embed aspect-16x9">
+	<iframe width="1280" height="720" src="https://www.youtube.com/embed/vUzIeg8frh4" title="Workshop: Intro to Coding for Graphite" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+</div>
+
+The Graphite editor is built as a web app powered by Svelte in the frontend and Rust in the backend which is compiled to WebAssembly (wasm) and run in the browser.
+
+The Editor's frontend web code lives in `/frontend/src` and the backend Rust code lives in `/editor`. The web-based frontend is intended to be semi-temporary and eventually replaceable with a pure-Rust GUI frontend. Therefore, all backend code should be unaware of JavaScript or web concepts and all Editor application logic should be written in Rust not JS.
+
+## Frontend/backend communication
+
+Frontend (JS) -> backend (Rust/wasm) communication is achieved through a thin Rust translation layer in `/frontend/wasm/src/editor_api.rs` which wraps the Editor backend's complex Rust data type API and provides the JS with a simpler API of callable functions. These wrapper functions are compiled by wasm-bindgen into autogenerated JS functions that serve as an entry point into the wasm.
+
+Backend (Rust) -> frontend (JS) communication happens by sending a queue of messages to the frontend message dispatcher. After the JS calls any wrapper API function to get into backend (Rust) code execution, the Editor's business logic runs and queues up `FrontendMessage`s (defined in `/editor/src/messages/frontend/frontend_message.rs`) which get mapped from Rust to JS-friendly data types in `/frontend/src/wasm-communication/messages.ts`. Various JS code subscribes to these messages by calling `subscribeJsMessage(MessageName, (messageData) => { /* callback code */ });`.
+
+## The Editor backend and Legacy Document modules
+
+The Graphite editor backend handles all the day-to-day logic and responsibilities of a user-facing interactive application. Some duties include: user input, GUI state management, viewport tool behavior, layer management and selection, and handling of multiple document tabs.
+
+The actual document (the artwork data and layers included in a saved `.graphite` file) is part of another core module located in `/document-legacy`. The (soon-to-be-replaced) Legacy Document codebase manages a user's document. Once it is replaced, the new Document module (that will be located in `/document`) will store a document's node graph and change history. While it's OK for the Editor to read data from—or make immutable function calls upon—the user's document controlled by the Legacy Document module, it should never be directly mutated. Instead, messages (called Operations) should be sent to the document to request changes occur. The Legacy Document code is designed to be used by the Editor or by third-party Rust or C/C++ code directly so a careful separation of concerns between the Editor and Legacy Document modules should be considered.
+
+## The message bus
+
+Every part of the Graphite stack works based on the concept of message passing. Messages are pushed to the front or back of a queue and each one is processed by the module's dispatcher in the order encountered. Only the dispatcher owns a mutable reference to update its module's state.
+
+### Additional technical details
+
+A message is an enum variant of a certain message sub-type like `FrontendMessage`, `ToolMessage`, `PortfolioMessage`, or `DocumentMessage`. Two example messages:
+```rs
+// Carries no data
+DocumentMessage::DeleteSelectedLayers
+
+// Carries a layer path and a string as data
+DocumentMessage::RenameLayer(Vec<LayerId>, String)
+```
+
+Message sub-types hierarchically wrap other message sub-types; for example, `DocumentMessage` is wrapped by `PortfolioMessage` via:
+```rs
+// Carries the child message as data
+PortfolioMessage::Document(DocumentMessage)
+```
+and `EllipseMessage` is wrapped by `ToolMessage` via:
+```rs
+// Carries the child message as data
+ToolMessage::Ellipse(EllipseMessage)
+```
+Every message sub-type is wrapped by the top-level `Message`, so the previous example is actually:
+```rs
+Message::Tool(ToolMessage::Ellipse(EllipseMessage))
+```
+
+Because this is cumbersome, we have a proc macro `#[child]` that automatically implements the `From` trait on message sub-types and lets you write:
+```rs
+DocumentMessage::DeleteSelectedLayers.into()
+```
+instead of:
+```rs
+Message(PortfolioMessage::Document(DocumentMessage::DeleteSelectedLayers))
+```
@@ -0,0 +1,47 @@
+++
+title = "Contributing guidelines"
+
+[extra]
+order = 2 # Page number after chapter intro
+++
+
+## Code style
+
+The Graphite project prizes code quality and accessibility to new contributors. Therefore, we ask you please make all efforts to contribute readable, well-documented code according to these best practices.
+
+### Naming
+
+Please use descriptive variable/function/symbol names and keep abbreviations to a minimum. Prefer to spell out full words most of the time, so `gen_doc_fmt` should be written out as `generate_document_format` instead.
+
+This avoids the mental burden of expanding abbreviations into semantic meaning. Monitors are wide enough to display long variable/function names, so descriptive is better than cryptic. To streamline code review, it's recommended that you set up a spellcheck plugin in your editor. The project uses American English spelling conventions.
+
+### Linting
+
+Please ensure Clippy is enabled. This should be set up automatically in VS Code. Try to avoid committing code with lint warnings.
+
+### Comments
+
+For consistency, please try to write comments in *Sentence case* (starting with a capital letter). End with a period only if multiple sentences are used in the same comment. For doc comments (`///`), always write in full sentences (ending with a period).
+
+Comments should be placed on a separate line, but exceptions are permitted where sensible. They should target the maximum line length of 200 characters (don't go over, and don't target a considerably lower number like 80 for line breaks).
+
+### Imports
+
+At the top of Rust files, please follow the convention of separating imports into three blocks, in this order:
+1. Local (`use super::` and `use crate::`)
+2. First-party crates (e.g. `use editor::`)
+3. Third-party libraries (e.g. `use std::` or `use serde::`)
+
+Combine related imports with common paths at the same depth. For example, the lines `use crate::A::B::C;`, `use crate::A::B::C::Foo;`, and `use crate::A::B::C::Bar;` should be combined into `use crate::A::B::C::{self, Foo, Bar};`. But do not combine imports at mixed path depths. For example, `use crate::A::{B::C::Foo, X::Hello};` should be split into two separate import lines. In simpler terms, avoid putting a `::` inside `{}`.
+
+## Tests
+
+It's great if you can write tests for your code, especially if it's a tricky stand-alone function. However at the moment, we are prioritizing rapid iteration and will usually accept code without associated unit tests. That stance will change in the near future as we begin focusing more on stability than iteration speed.
+
+## Draft pull requests
+
+Once you begin writing code, please open a pull request immediately and mark it as a **Draft**. Please push to this on a frequent basis, even if things don't compile or work fully yet. It's very helpful to have your work-in-progress code up on GitHub so the status of your feature is less of a mystery.
+
+Open a new PR as a draft / convert an existing PR to a draft:
+
+![Screenhots showing GitHub's "Create pull request (arrow) > Create draft pull request" and "Still in progress? Convert to draft" buttons](https://static.graphite.rs/content/contribute/draft-pr.png)
@@ -0,0 +1,30 @@
+++
+title = "Debugging"
+
+[extra]
+order = 1 # Page number after chapter intro
+++
+
+## Deployed builds
+
+When tracking down a bug, first check if the issue you are noticing also exists in `master` or just your branch. Use [dev.graphite.rs](https://dev.graphite.rs) which should always deploy the lastest commit on `master`. By comparison, [editor.graphite.rs](https://editor.graphite.rs) is manually updated every few days or weeks to ensure stability. Use *Help* > *About Graphite* in the editor to view the build's [commit hash](https://github.com/GraphiteEditor/Graphite/commits/master).
+
+## Printing to the console
+
+Use the browser console (<kbd>F12</kbd>) to check for warnings and errors. Use the Rust macro `debug!("A debug message");` to print to the browser console. These statements should be for temporary debugging. Remove them before committing to `master`. Print-based debugging is necessary because breakpoints are not supported in WebAssembly.
+
+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*.
+
+## Message system logs
+
+To also view logs of the messages dispatched by the message bus system, activate *Help* > *Debug: Print Messages* > *Only Names*. Or use *Full Contents* for more verbose insight with the actual data being passed. This is an invaluable window into the activity of the message flow and works well together with `debug!()` printouts for tracking down message-related issues.
+
+## Layer paths and document IDs
+
+In debug mode, hover over a layer's name in the Layer Tree panel to view a tooltip with its `u64` path. Likewise, document IDs may be read by hovering over their tabs.
@@ -0,0 +1,16 @@
+++
+title = "Tech stack"
+
+[extra]
+order = 3 # Page number after chapter intro
+++
+
+- rustc: Compiler for node graph generics and custom nodes
+- rust-gpu: Compiler backend to generate compute shaders from Rust source code
+- wgpu: Portable graphics API for running compute shaders on desktop and web
+- Tauri: lightweight desktop web UI shell while the backend runs natively (experimental)
+<!-- - Vello: GPU-accelerated vector graphics renderer -->
+<!-- - COSMIC Text: Text shaping and typesetting -->
+<!-- - Wasmer or Wasmtime: Portable, sandboxed runtime for custom nodes -->
+<!-- - Tokio: parallelized job execution in the node graph pipeline -->
+<!-- - Xilem: High-performance native UI framework, to replace Tauri when ready -->
@@ -0,0 +1,48 @@
+++
+title = "Getting started"
+template = "book.html"
+page_template = "book.html"
+
+[extra]
+order = 1 # Chapter number
+++
+
+Graphite is built with Rust and web technologies. Install the latest LTS version of [Node.js](https://nodejs.org/) and stable release of [Rust](https://www.rust-lang.org/), as well as [Git](https://git-scm.com/).
+
+## Installing
+
+Clone the project:
+```sh
+git clone https://github.com/GraphiteEditor/Graphite.git
+```
+
+Then install the required Node.js packages:
+```sh
+cd frontend
+npm install
+```
+
+You only need to explicitly install Node.js dependencies. Rust's cargo dependencies will be installed automatically on your first build. One dependency in the build chain, `wasm-pack`, will be installed automatically on your system when the Node.js packages are installing. (If you prefer to install this manually, get it from the [wasm-pack website](https://rustwasm.github.io/wasm-pack/), then install your npm dependencies with `npm install --no-optional` instead.)
+
+One tool in the Rust ecosystem does need to be installed:
+
+```
+cargo install cargo-watch
+```
+
+That's it! Now, to run the project while developing, just execute:
+```
+npm start
+```
+
+This spins up the dev server at <http://localhost:8080> with a file watcher that performs hot reloading of the web page. You should be able to start the server, edit and save web and Rust code, and rarely have to kill the server (by hitting <kbd>Ctrl</kbd><kbd>C</kbd> twice). You sometimes may need to reload the browser's web page if the hot reloading didn't behave perfectly. This method compiles Graphite code in debug mode which includes debug symbols for viewing function names in stack traces. But be aware, it runs slower and takes more memory.
+
+## Production builds
+
+You'll rarely ever need to do this, but to compile a production build with full optimizations:
+```sh
+cargo install cargo-about
+npm run build
+```
+
+It produces the `/frontend/dist` directory containing the static site files that must be served by your own web server.
@@ -0,0 +1,14 @@
+++
+title = "Editor and tooling"
+
+[extra]
+order = 1 # Page number after chapter intro
+++
+
+We provide default configurations for VS Code users. When you open the project, watch for a prompt to install the project's suggested extensions. They will provide helpful web and Rust tooling. If you use a different IDE, you won't get default configurations for the project out of the box, so please remember to format your code and check CI for errors.
+
+## Checking, linting, and formatting
+
+While developing Rust code, `cargo check`, `cargo clippy`, and `cargo fmt` terminal commands may be run from the root directory. For web code, `npm run lint` and `npm run lint-no-fix` can be used from the `/frontend` directory to fix or view formatting issues.
+
+If you don't use VS Code and its format-on-save feature, please remember to format before committing or consider [setting up a `pre-commit` hook](https://githooks.com/) to do that automatically. Disabling VS Code's *Auto Save* files feature is recommended to ensure you actually save (and thus format) file changes.
@@ -0,0 +1,14 @@
+++
+title = "Getting help"
+
+[extra]
+order = 3 # Page number after chapter intro
+++
+
+## Discord developer community
+
+Join the [project's Discord server](https://discord.graphite.rs) then hop on the `#development` channel and ping @Keavon, @TrueDoctor, or @0Hypercube. The team would be delighted to help you get started by providing in-depth explanations of the code and programming assistance as you work. Please do not hesitate to reach out right away!
+
+## Code documentation
+
+Look out for `README.md` files in some folders of the codebase and doc comments at the top of some Rust files. The quantity of those files is limited right now, but documenting code is an excellent contribution if you wish to explain what you've learned for the sake of others, and improve your own understanding in the process.
@@ -0,0 +1,17 @@
+++
+title = "Picking a task"
+
+[extra]
+order = 2 # Page number after chapter intro
+++
+
+The [task board](https://github.com/orgs/GraphiteEditor/projects/1/views/1) provides a list of [available tasks](https://github.com/orgs/GraphiteEditor/projects/1/views/5), as well as a [beginner-friendly](https://github.com/orgs/GraphiteEditor/projects/1/views/6) subset.
+
+If you have Rust and/or web experience, you may also pick based on:
+- [Only Rust](https://github.com/orgs/GraphiteEditor/projects/1/views/5?filterQuery=status%3AShort-Term%2CMedium-Term%2CLonger-Term+label%3ARust+-label%3AWeb) tasks
+- [Only web](https://github.com/orgs/GraphiteEditor/projects/1/views/5?filterQuery=status%3AShort-Term%2CMedium-Term%2CLonger-Term+label%3AWeb+-label%3ARust) tasks (HTML/CSS/TypeScript/Svelte)
+- [Combined Rust and web](https://github.com/orgs/GraphiteEditor/projects/1/views/5?filterQuery=status%3AShort-Term%2CMedium-Term%2CLonger-Term+label%3ARust+label%3AWeb) tasks
+
+Feel free to pick whatever task interests you, then comment on the issue that you would like to start. After commenting, you can dig in right away, then we will assign the issue to your GitHub user to keep the work status of tasks organized.
+
+Writing new documentation by commenting existing code is another valuable way to contribute as you learn.
@@ -0,0 +1,18 @@
+++
+title = "Product design"
+template = "book.html"
+page_template = "book.html"
+
+[extra]
+order = 3 # Chapter number
+++
+
+**NOTE: Developers probably don't need to read this chapter.**
+
+A vital part in the success of open source software development is having a clear vision and direction for the product design. Failure to pull that off is a leading factor in the stagnation and mediocrity of many software projects.
+
+The Graphite project's founder and its principal product designer, Keavon, is in charge of maintaining and evolving the product design to ensure cohesion within the development process. This ranges from building the user interface design system and content layout as a mockup before it's replicated in HTML/CSS, to determining user workflows, to translating high-level goals into the constraints and requirements of specific features for the development team.
+
+The hardest part is translating an always-evolving network of ideas and thoughts comprehensively into written form in order to communicate the big (and little) ideas to collaborators. As the product develops, the design grows alongside the code and real usage of the developed features helps bring clarity to what's planned next. Since the design process never stops evolving, any attempt to write it down is inevitably doomed to become out of date. And the multitudes of mental state can't possibly all be written down.
+
+Despite the challenges with documenting design, this chapter aims to provide a living catalog of ideas surrounding some topics in the product design process. It won't be organized, nor complete, nor will it be always current. The best way to seek clarity about a topic is asking Keavon about it on Discord. **This chapter is optional reading** and is likely of minimal relevance to most code contributors.
@@ -0,0 +1,68 @@
+++
+title = "Glossary of terminology"
+
+[extra]
+order = 3 # Page number after chapter intro
+++
+
+**NOTE: This is old. Some parts may not match current usage.**
+
+### Document
+A design source file created and edited in the Graphite editor. Saved to disk as a Graphite Design Document in a _GDD file_. Documents can be included as _layers_ inside other documents, and in doing so they take the form of _groups_. The _layer graph_ contents of a _group_ actually belong to the _embedded_ document's _subgraph_. Because a document is a _group_ which is a _layer_ in the _layer graph_, documents have _properties_ such as the _frames_ in the _canvas_. Documents are composed of a layer graph, a defined set of properties of set _data types_ that are _imported_ and _exported_, and the _properties_ of the _root layer_.
+### Asset
+A portable mechanism for distributing a "compiled" Graphite _document_ in a format that is immediately ready for rendering. Saved to disk as a Graphite Digital Asset in a _GDA file_. Assets are created by "flattening" a _document's_ complex, nested _layer graph_ structure into a single, simple directed acyclic graph (DAG). The Graphite editor internally maintains an asset version of any open _document_ in order to draw the _canvas_ live in the _viewport_. An asset also includes certain exposed _properties_ of specified _data types_ that are _imported_ and _exported_, as defined by the asset's author in the source _document's_ _layer graph_. They can be shared and _embedded_ in another _layer graph_ as a black box (meaning it can't be expanded to reveal or edit its interior graph), as compared to _embedded_ _documents_ from _GDD files_ which are white boxes (they can be expanded to reveal their _subgraph_ which can be edited). Assets are helpful for defining custom _nodes_ that perform some useful functionality. Tangible examples include custom procedural effects, shape generators, and image filters. Many of the Graphite editor's own built-in _nodes_ are actually assets rather than being implemented directly in code. The _Asset Manager_ panel helps maintain these assets from various sources. The _Asset Store_ can be used to share and sell assets for easy inclusion in other projects.
+### GDD file
+Graphite Design Document. A binary serialization of a _document_ source file. The format includes a chain of _operations_ that describe changes to the _layer graph_ and the _properties_ of _layers_ throughout the history of the document since its creation. It also stores certain metadata and the raw data of _embedded_ files. Because GDD files are editable (unlike _GDA files_), the _layers_ of GDD files imported into another _document_ may be expanded in its _layer graph_ to reveal and modify their contents using a copy-on-write scheme stored to the _asset's_ _layer_.
+### GDA file
+Graphite Digital Asset. A binary serialization of an _asset_ file. Because GDA files are read-only and can't be edited (unlike _GDD files_), the _layers_ created from _assets_ do not offer an ability to be expanded in the _layer graph_ of a _document_ that _embeds_ them. GDA files are useful for sharing _assets_ when their authors do not wish to provide the source _documents_ to author them. _DGA files_ are also the input format included in games that utilize the _Graphite Renderer Core Library_ to render graphical content at runtime, as well as similar applications like headless renderers on web servers and image processing pipelines.
+### Window
+### Main window
+### Popout window
+### Title bar
+### Status bar
+### Workspace
+The part of the Graphite editor's UI that houses the _panels_ in a _window_. The workspace occupies the large space below the _title bar_ and above the _status bar_ of the _main window_. It occupies the entirety of _popout windows_ (window buttons are added in the _tab bar_).
+### Workspace layout
+The specific configuration of panels in the _main window_ and any _popout windows_. Workspace layout presets are provided by the Graphite editor and users may customize and save their own.
+### Tab bar
+The bar at the top of a _panel group_ which includes a clickable tab for each panel that is docked there. Each tab bar has at least one tab and one active tab.
+### Active tab
+The one tab in a _tab bar_ that is currently active. The user can click any inactive tab to make it become the active tab. The active tab shows the _panel content_ beneath it unless it is a _folded panel_.
+### Folded panel
+A shrunken _panel_ showing only the _tab bar_. A _panel_ consists of the _tab bar_ and _panel body_ except when the latter is folded away. The user may click the _active tab_ to fold and restore a panel, however a panel cannot be folded if there are no other unfolded panels in its column.
+### Panel
+### Panel body
+### Options bar
+The bar that spans horizontally across the top of a _panel_ (located under the _tab bar_) which displays options related to the _panel_.
+### Viewport
+The area that takes up the main space in a _panel_ (located beneath the _options bar_) which displays the primary content of the _panel_.
+### Shelf
+The bar that spans vertically along the left side of some _panels_ (located left of the _viewport_) which displays a catalog of available items, such as document editing _tools_ or common _nodes_.
+### Tool
+An instrument for interactively editing _documents_ through a collection of related behavior. Each tool puts the editor into a mode that provides the ability to perform certain _operations_ on the document interactively. Each _operation_ is run based on the current context of mouse and modifier buttons, key presses, tool options, selected layers, editor state, and document state. The _operations_ that get run are appended to the document history and update the underlying _layer graph_ in real time.
+### Canvas
+The infinite coordinate system that shows the visual output of an open _document_ at the current zoom level and pan position. It is drawn in the document panel's _viewport_ within the area inside the scroll bars on the bottom/right edges and the _rulers_ on the top/left edges. The canvas can be panned and zoomed in order to display all or part of the artwork in any _frames_. A canvas has a coordinate system spanning infinitely in all directions with an origin always located at the top left of the primary _artboard_. The purpose of an infinite canvas is to offer a convenient editing experience when there is no logical edge to the artwork, for example a loosely-arranged board of logo design concepts, a mood board, or whiteboard-style notes.
+### Artboard
+An area inside a _canvas_ that provides rectangular bounds to the artwork contained within, as well as default bounds for an exported image. The _Artboard tool_ adjusts the bounds and placement of frames in the _document_ and each artboard is stored in a "artboard list" property of the _root layer_. When there is at least one artboard, the infinite _canvas_ area outside any artboard displays a configurable background color. Artwork can be placed outside of a artboard but it will appear mostly transparent. The purpose of using one artboard is to provide convenient cropping to the edges of the artwork, such as a single digital painting or photograph. The purpose of using multiple frames is to work on related artwork with separate bounds, such as the layout for a book.
+### Layer graph
+A (directed acyclic) graph structure composed of _layers_ with _connections_ between their input and output _ports_. This is commonly referred to as a "node graph" in other software, but Graphite's layer graph is more suited towards layer-based compositing compared to traditional compositor node graphs.
+### Node
+A definition of a _layer_. A node is a graph "operation" or "function" that receives input and generates deterministic output.
+### Layer
+Any instance of a _node_ that lives in the _layer graph_. Layers (usually) take input data, then they transform it or synthesize new data, then they provide it as output. Layers have _properties_ as well as exposed input and output _ports_ for sending and receiving data.
+### Root layer
+### Group
+### Raster
+### Vector
+### Mask
+### Data type
+### Subgraph
+### Port
+### Connection
+### Core Libraries
+### Graphite Editor (Frontend)
+### Graphite Editor (Backend)
+### Graphene (Node Graph Engine)
+### Trace
+### Path
+### Shape
@@ -0,0 +1,108 @@
+++
+title = "Product outline"
+
+[extra]
+order = 1 # Page number after chapter intro
+++
+
+**NOTE: This is old. Some parts may not match current usage.**
+
+- Interface
+	- Title bar
+		- Menu bar
+		- Focused document title
+		- Window buttons
+	- Workspace
+		- Panel interface (tab, pin, options bar, left menu)
+		- Arrangement and docking
+	- Status bar
+	- Multiple windows
+- Panels
+	- Document
+		- Canvas and frames
+		- Rulers
+		- Tool menu
+		- Options bar
+	- Properties
+		- Blending
+		- Origin
+		- Transform
+		- Node-specific properties
+	- Layers
+		- Interface
+		- Compositing flow
+		- Groups
+		- Masks
+		- Isolation
+	- Graph
+		- Interface
+		- Layer/node equivalence
+		- Compositing flow
+		- Groups
+		- Masks
+		- Isolation
+	- Connection Matrix
+	- Spreadsheet
+	- Node Catalog
+	- Asset Manager
+		- Embedded assets
+		- Linked assets
+			- Local assets
+			- Remote assets
+		- Store assets
+		- Out-of-the-box assets
+		- Extension-provided assets
+	- Palettes
+		- Each color palette is an asset
+	- Minimap
+	- Histogram
+	- Timeline
+- Documents and assets
+	- Node groups, layer groups, and document tabs are equivalent
+	- Groups/documents are assets
+	- Assets are embedded or linked
+	- The document canvas is a group output
+	- Art boards and dimensions
+	- Reusable assets
+- Tools
+	- Overview
+		- Tools add and update assets
+	- General tool group
+	- Vector tool group
+	- Raster tool group
+- Masking
+	- Mask mode
+- Vector editing
+	- Data types
+	- Data flow
+	- Rasterization
+- Raster editing
+	- Resolution-agnostic sampling
+	- Compositing and data flow
+	- Caching
+	- Predictive caching
+	- Progressive enhancement
+	- Generator nodes
+	- Rasterizer nodes
+	- Adjustment nodes
+	- Filter nodes
+	- Sample transformer nodes
+	- Historical sampling
+- Text editing
+- Data types
+- Node types
+- Node library
+- File format interoperability
+	- Import/export: JPG, PNG, APNG, GIF, TIFF, TGA, BMP, JPEG 2000, WebP, HEIF, ICO
+	- Import/export: EXR
+	- Import: digital camera raw formats
+	- Import/export: SVG
+	- Import/export: EPS
+	- Import/export: PDF
+	- Import: PSD/PSB, AI, INDD?
+	- Export: G-code formats for laser and vinyl cutters?
+- Extensions
+- Color management
+- Units, measurement, and scale
+- Headless and integrations
+- Animation
@@ -0,0 +1,115 @@
+++
+title = "Uses and workflows"
+
+[extra]
+order = 2 # Page number after chapter intro
+++
+
+**NOTE: This is old. Some parts may not match current usage.**
+
+This list describes some long-term aspirational goals and ideas. It represents an incomplete brainstorm idea dump, not a roadmap.
+
+## Use cases
+
+General goals for product capabilities are categorized by discipline below.
+
+### Photography
+- RAW photo editing/processing
+- Batch processing pipeline
+
+### Motion graphics
+- Title sequences/kinetic typography/etc.
+
+### Live broadcast/streaming
+- Live video compositing/overlays
+- Interactive exhibits (rendering live content for museum/art/festival exhibits)
+
+### Web
+- SVG design
+- Animated or interactive SVG design
+
+### Automation
+- Batch multimedia editing/conversion
+
+### Graphic design
+- Print design
+- Web/digital-focused graphics (marketing, branding, infographics, ads, etc.)
+- Templates filled with file/spreadsheet data (e.g. prototyping/iterating components of a board/card game)
+
+### Illustration
+- Digital painting
+- Logo and icon design
+
+### Desktop publishing
+- Templates filled with Markdown/HTML content with export to PDF
+
+### Video compositing
+
+### Data Visualization
+- Data-powered graphs/charts/etc.
+- Automated rendering with live/often-updated data
+
+### 3D/Gamedev
+- PBR procedural material authorship
+- 3D model UV map texturing
+
+### AI-assisted tools
+
+### HDR processing
+
+### 360° and panoramic stitching and spherical editing
+
+## User stories
+
+Example user workflows are categorized by discipline below.
+
+### Photography
+- Using a face detection node to sort photos into the correct folders upon export
+- Using a face detection node to place a watermark near every face to prevent customers from cropping out watermarks placed in less important areas of some photos
+- Shadow removal from part of an image by masking the location of a shadow and using the texture details of the darker area and the lighting and color context of the illuminated area
+- Lightening or contextually infilling all the areas where a camera sensor has dust specks
+- Isolating clipping highlights (that have expanded into neighboring pixels) in one or more color channels from point light sources like city lights and rendering smoother bright gradient point lights in place of them
+- Advanced, intuitive blending with a node that lets you create a "custom blend mode" by specifying something like "Anything that's white: display as is. Anything else further from white by luminosity: fade out the saturation and opacity."
+
+### Image editing
+- Removing translucent watermarks that were applied in the same location to a batch of photos by finding their shared similarities and differences and using that as a subtraction diff
+
+### Game development
+- Design a GUI for the game and use Graphene to render the in-game GUI textures at runtime at the desired resolution without scaling problems, or even render it live as data updates its state
+- Authoring procedural noise-based textures and PBR materials
+
+### Data visualization
+- Creating a chart from a CSV
+- Rendering an always-up-to-date chart powered by real-time updates from a database
+- Data-driven infographics like an org chart that can be updated with text instead of manual design work
+- Rendering a timelapse video of every operation done in the history of a document
+
+### Digital painting
+- Creating a digital acrylic or oil painting using various brushes
+- Preventing mixing/smearing of previous wet paint layers by drying it with a hair dryer tool
+- Smearing wet paint colors together on a simulated paint palette and then sampling paint colors from that palette to paint with
+
+### Graphic design
+- Prototyping cards for board games fed with data in a spreadsheet which generates the cards from a template
+- Creating an image that has been shredded but pieced back together, where the image can be updated then return to the shredded one without having to redo the editing steps to shred it
+
+### Broadcast, interactive exhibits, and digital signage
+- Rendering overlays for live streams or television broadcasts based on live input data, for example somebody donates and leaves a comment on a live stream and this web hook could trigger an animated display containing the user and their comment, or live telemetry for a rocket launch streams in and gets rendered as graphical overlays for a webcast.
+- Rendering a custom live clockface with hour/minute/second hands based on an input of the current time, then showing them fullscreen on a display
+- Request the weather from an API and render live visualizations which gets displayed on a monitor in your house or a museum (export to a Windows screen saver?)
+- Data from sensors can render interactive 2D graphics at a museum art installation
+- A storefront can have a monitor set up showing daily or hourly sales items based on web hooks or polling from the company’s website
+- Polling an API for content like Twitter or an RSS feed and displaying the tweet or headline when it arrives on screen, styled as desired
+
+### Print and publishing
+- Formatting Markdown documents into PDF print layouts
+- Laying out book covers for proper PDF export to a printer
+- Typesetting and formatting all the interior pages of a book with manual control where needed
+
+### Automation
+- Laser cutter artwork processing for automating custom Etsy orders
+- Running on a server to let users upload images for a custom T-shirt printing website, and it renders their graphic on the model’s shirt (or other custom printing online stores)
+- Generating a PDF invoice based on data in a pipeline on a server
+
+### Computer vision and industrial control
+- Factory line is examining its fruit for defects. In order to verify the quality, they need to enhance the contrast, automatically orient the image and correct the lighting. They then pass the results into a machine learning algorithm to classify, and sometimes need to snoop on the stream of data to manually do quality control (ImageMagick or custom Python scripts are often used for this right now)