Introduction

Welcome to the Unofficial GPUI Cheat Book!

This book is a practical, concise reference for building applications with GPUI, the UI framework from the creators of Zed. This cheat book focuses on getting you up to speed by providing common patterns, recipes, and solutions to typical problems you’ll encounter.

What is GPUI?

GPUI is a fast, productive UI framework for Rust that powers the Zed editor. It offers:

Performance: GPU-accelerated rendering with efficient state management
Flexibility: Three levels of abstraction from high-level declarative UI to low-level custom elements
Ergonomics: Tailwind-inspired styling API and reactive state management

What This Book Covers

This book complements the official documentation and gpui.rs examples by providing:

Practical patterns for common UI tasks
Real-world examples beyond hello world
Best practices from the Zed codebase
Pitfalls to avoid
Recipes for building complete features

What This Book Doesn’t Cover

This book assumes you’re already familiar with:

Rust basics
The examples on gpui.rs
Basic GPUI concepts (you’ve read the README)

For comprehensive API documentation, see the GPUI repository.

How to Use This Book

Linear reading: Start with “Getting Started” if you’re new to GPUI
Reference: Jump to specific topics when you need them
Cookbook: Copy and adapt recipes for your needs

Contributing

This is an unofficial, community-maintained resource. Contributions, corrections, and suggestions are welcome!

Let’s get started with Setup!

Setup

This section covers getting your development environment ready for GPUI development.

Topics

Development Environment - Tools and dependencies
Your First GPUI App - Building hello world from scratch

Prerequisites

Before starting with GPUI, you should have:

Rust toolchain installed (rustup recommended)
Basic familiarity with Rust
A code editor with Rust support

Quick Start

cargo new my-gpui-app
cd my-gpui-app
cargo add gpui

See Your First GPUI App for a complete walkthrough.

Development Environment

TODO: This section is a work in progress.

Platform-Specific Setup

Linux

TODO: Document Linux dependencies (X11/Wayland, etc.)

macOS

TODO: Document macOS setup

Windows

TODO: Document Windows setup

Recommended Tools

TODO: List helpful tools for GPUI development

rust-analyzer
cargo-watch
etc.

IDE Configuration

TODO: Tips for setting up your IDE/editor

Your First GPUI App

TODO: This section is a work in progress.

Creating the Project

TODO: Step-by-step project creation

Adding Dependencies

TODO: Cargo.toml setup

Hello World

TODO: Complete hello world example with explanation

Running the App

TODO: How to build and run

Next Steps

TODO: Where to go from here

GPUI Fundamentals

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

The Three Registers

GPUI offers three different levels of abstraction, called “registers”, that you can choose from depending on your needs. You can mix and match these approaches in the same application.

The Three Levels

1. State Management (Entities)

When to use: Managing application state that needs to communicate between different parts of your app.

Entities are GPUI’s solution for state management. They’re similar to Rc<RefCell<T>> but owned by GPUI itself, and can only be accessed through the framework’s context APIs.

struct Counter {
    count: i32,
}

// Create an entity
let counter = cx.new(|_cx| Counter { count: 0 });

// Update it later
counter.update(cx, |this, cx| {
    this.count += 1;
    cx.notify(); // Tell observers about the change
});

// Read it
let current_count = counter.read(cx).count;

Key features:

Owned by GPUI, accessed via Entity<T> handles
Observable: other parts of your app can react to changes
Safe concurrent access through the context system

See Entities and Ownership for details.

2. High-Level Declarative UI (Views)

When to use: Building most of your user interface.

Views are entities that can be rendered by implementing the Render trait. This is the main way you’ll build UIs in GPUI. Think of it like React components or SwiftUI views.

struct CounterView {
    counter: Entity<Counter>,
}

impl Render for CounterView {
    fn render(&mut self, cx: &mut ViewContext<Self>) -> impl IntoElement {
        let count = self.counter.read(cx).count;

        div()
            .flex()
            .flex_col()
            .gap_2()
            .child(format!("Count: {}", count))
            .child(
                div()
                    .bg(rgb(0x2563eb))
                    .text_color(white())
                    .px_4()
                    .py_2()
                    .rounded_md()
                    .child("Increment")
                    .on_click(cx.listener(|this, _event, cx| {
                        this.counter.update(cx, |counter, cx| {
                            counter.count += 1;
                            cx.notify();
                        });
                    }))
            )
    }
}

Key features:

Tailwind-inspired styling API (.flex(), .px_4(), etc.)
Declarative: describe what the UI should look like
Reactive: automatically re-renders when state changes
Built on top of the element system

See Views and Rendering for details.

3. Low-Level Imperative UI (Elements)

When to use: Maximum control and performance (custom lists, text editors, complex layouts).

Elements are the building blocks that views create. You can implement the Element trait directly for complete control over layout and rendering.

struct CustomElement {
    // Your state
}

impl Element for CustomElement {
    fn request_layout(
        &mut self,
        _: &WindowContext,
        style: &StyleRefinement,
        cx: &mut LayoutContext,
    ) -> LayoutId {
        // Define your custom layout using Taffy
        cx.request_layout(style, None)
    }

    fn prepaint(
        &mut self,
        _: &Bounds<Pixels>,
        _: &mut WindowContext,
        cx: &mut PaintContext,
    ) {
        // Register hitboxes and prepare for painting
    }

    fn paint(
        &mut self,
        bounds: &Bounds<Pixels>,
        _: &mut WindowContext,
        cx: &mut PaintContext,
    ) {
        // Custom drawing code
        cx.paint_quad(/* ... */);
    }
}

Key features:

Total control over layout and rendering
Maximum performance (e.g., UniformList for virtualized lists)
Direct access to GPU rendering primitives
More complex but more powerful

See Custom Elements for details.

Choosing the Right Register

Register	Use When	Examples
Entities	You need shared, observable state	App settings, document state, shared counters
Views	Building standard UI (90% of the time)	Buttons, forms, layouts, most components
Elements	You need maximum control/performance	Text editors, large lists, custom rendering

Mixing Registers

You’ll typically use all three together:

Entities store your application state
Views render UI based on that state
Elements provide the primitives that views are built from (usually you just use the built-in ones like div())

// Entity for state
struct AppState {
    items: Vec<String>,
}

// View that uses the state
struct ListView {
    state: Entity<AppState>,
}

impl Render for ListView {
    fn render(&mut self, cx: &mut ViewContext<Self>) -> impl IntoElement {
        let items = self.state.read(cx).items.clone();

        // Using built-in elements (div, uniform_list)
        uniform_list(items, |item, _cx| {
            div().child(item)
        })
    }
}

Next Steps

Learn about Entities and Ownership
Understand Contexts - your interface to GPUI
Deep dive into Views and Rendering

Entities and Ownership

In GPUI, you don’t own your data - the App does. Every model or view in your application is actually owned by a single top-level object called the App. This might feel strange coming from regular Rust, but it’s the foundation of GPUI’s reactive state management.

The Key Insight

Think of Entity<T> like an Rc<RefCell<T>>, except:

The App owns the actual data
You hold a handle (Entity<T>) that’s just an identifier
You can only access the data when you have a reference to the App (via a context)

This design enables GPUI’s observer pattern, where changes to one entity can automatically notify others.

Creating Entities

You create entities using cx.new():

use gpui::{App, Application, Entity};

struct Counter {
    count: i32,
}

Application::new().run(|cx: &mut App| {
    // Give ownership to the App, get back a handle
    let counter: Entity<Counter> = cx.new(|_cx| Counter { count: 0 });
});

The Entity<Counter> handle is:

Cheap to clone (reference counted)
Type-safe (carries Counter type information)
Inert by itself (can’t access data without a context)

Accessing Entity Data

Reading

Use .read(cx) for immutable access:

let count = counter.read(cx).count;
println!("Count: {}", count);

Updating

Use .update(cx, |entity, cx| { ... }) for mutable access:

counter.update(cx, |counter, cx| {
    counter.count += 1;
    cx.notify(); // Tell observers about the change
});

The callback receives:

&mut Counter - mutable reference to your data
&mut Context<Counter> - entity-specific context for services

Notifying Observers

When you change an entity’s state, call cx.notify() to inform observers:

counter.update(cx, |counter, cx| {
    counter.count += 1;
    cx.notify(); // Triggers observers
});

Without cx.notify(), other parts of your app won’t know the state changed!

Observing State Changes

Use cx.observe() to react when an entity’s state changes:

struct Counter {
    count: i32,
}

Application::new().run(|cx: &mut App| {
    let first_counter = cx.new(|_cx| Counter { count: 0 });

    let second_counter = cx.new(|cx| {
        // Set up observation during creation
        cx.observe(&first_counter, |second, cx| {
            // This runs whenever first_counter calls cx.notify()
            second.count = first_counter.read(cx).count * 2;
        })
        .detach(); // Keep observing until entities are dropped

        Counter { count: 0 }
    });

    // Update first counter
    first_counter.update(cx, |counter, cx| {
        counter.count += 1;
        cx.notify(); // Triggers second_counter's callback
    });

    assert_eq!(second_counter.read(cx).count, 2);
});

Key points:

The observer callback gets &mut Self (the observer) and &mut Context<Self>
Access the observed entity using its handle from the outer scope
Call .detach() to keep the subscription alive until the entities are dropped
Or store the Subscription and drop it to cancel observation

Event Emission (Typed Events)

For more structured communication, emit typed events:

use gpui::EventEmitter;

struct Counter {
    count: i32,
}

struct CounterChangeEvent {
    increment: i32,
}

// Enable Counter to emit this event type
impl EventEmitter<CounterChangeEvent> for Counter {}

Application::new().run(|cx: &mut App| {
    let first_counter = cx.new(|_cx| Counter { count: 0 });

    let second_counter = cx.new(|cx| {
        // Subscribe to specific event type
        cx.subscribe(&first_counter, |second, _first, event, _cx| {
            // event is CounterChangeEvent
            second.count += event.increment * 2;
        })
        .detach();

        Counter { count: 0 }
    });

    first_counter.update(cx, |counter, cx| {
        counter.count += 2;
        cx.emit(CounterChangeEvent { increment: 2 }); // Emit typed event
    });

    assert_eq!(second_counter.read(cx).count, 4);
});

Method	When to Use	What You Get
`cx.observe()`	React to any state change	Just the entity handle
`cx.subscribe()`	React to specific events	The typed event data

Rule of thumb: Use observe for “something changed”, use subscribe for “here’s what changed”.

Common Patterns

Pattern 1: Shared State

Multiple views sharing a single state entity:

struct AppState {
    user: String,
}

struct HeaderView {
    state: Entity<AppState>,
}

struct FooterView {
    state: Entity<AppState>,
}

// Both views hold the same Entity<AppState> handle
let state = cx.new(|_| AppState { user: "Alice".into() });
let header = cx.new(|_| HeaderView { state: state.clone() });
let footer = cx.new(|_| FooterView { state: state.clone() });

Pattern 2: Parent-Child Communication

Child notifies parent of changes:

struct ChildView {
    value: String,
}

impl EventEmitter<ChildChangedEvent> for ChildView {}

struct ParentView {
    child: Entity<ChildView>,
}

impl ParentView {
    fn new(cx: &mut Context<Self>) -> Self {
        let child = cx.new(|_| ChildView { value: String::new() });

        cx.subscribe(&child, |parent, child, event, cx| {
            // React to child events
            cx.notify(); // Propagate to parent's observers
        }).detach();

        Self { child }
    }
}

Pattern 3: Weak Handles (Avoiding Cycles)

Use WeakEntity to avoid reference cycles:

struct Parent {
    child: Entity<Child>,
}

struct Child {
    parent: WeakEntity<Parent>, // Weak reference breaks the cycle
}

let parent = cx.new(|cx| {
    let parent_weak = cx.weak_entity(); // Get weak reference to self

    let child = cx.new(|_| Child {
        parent: parent_weak,
    });

    Parent { child }
});

Pitfalls

Forgetting to Notify

// ❌ Bad: Changes but doesn't notify
counter.update(cx, |counter, _cx| {
    counter.count += 1;
    // Observers won't be notified!
});

// ✅ Good: Always notify after changes
counter.update(cx, |counter, cx| {
    counter.count += 1;
    cx.notify();
});

Detaching Subscriptions

// ❌ Bad: Subscription dropped immediately
cx.observe(&other, |this, cx| {
    // This will never run!
});

// ✅ Good: Detach to keep it alive
cx.observe(&other, |this, cx| {
    // This will run whenever `other` notifies
}).detach();

// ✅ Also good: Store it to control lifetime
let subscription = cx.observe(&other, |this, cx| {
    // Runs until subscription is dropped
});
self.subscription = Some(subscription);

Reference Cycles

// ❌ Bad: Creates a reference cycle
struct Node {
    next: Option<Entity<Node>>, // Strong reference
    prev: Option<Entity<Node>>, // Strong reference = cycle!
}

// ✅ Good: Use weak references to break cycles
struct Node {
    next: Option<Entity<Node>>,
    prev: Option<WeakEntity<Node>>, // Weak reference
}

Next Steps

Learn about Contexts - the different context types and their APIs
See State Management Patterns for real-world examples
Read the official tutorial

Contexts (App, Visual, Context<T>)

Contexts are your main interface to GPUI. Every interaction with the framework - creating entities, opening windows, rendering UI - goes through a context. GPUI provides three context types, each with progressively more capabilities.

The Three Context Types

App (fewest capabilities)
 ├── VisualContext (adds window/UI capabilities)
     └── Context<T> (adds entity-specific capabilities)

App - Application Context

The base context for all application-level services. Available everywhere.

Capabilities:

Create and manage entities
Access global state
Spawn async tasks
Manage platform services

Where you’ll see it:

Application::new().run(|cx: &mut App| {
    // Application startup
});

VisualContext - Window-Aware Context

Extends App with window and UI capabilities. Available when you’re working with windows or views.

Additional capabilities beyond App:

Open windows
Focus management
Access to window-specific services

Where you’ll see it:

cx.open_window(WindowOptions::default(), |cx| {
    // cx is a VisualContext here
    cx.new(|_| MyView::default())
})

Context<T> - Entity-Specific Context

The most powerful context, tied to a specific entity. Extends VisualContext with entity-level services.

Additional capabilities beyond VisualContext:

cx.notify() - notify observers of this entity
cx.emit() - emit typed events from this entity
cx.observe() - observe other entities
cx.subscribe() - subscribe to events from other entities
cx.entity() / cx.weak_entity() - get handle to self

Where you’ll see it:

let counter = cx.new(|cx: &mut Context<Counter>| {
    // cx knows it's for a Counter entity
    Counter { count: 0 }
});

counter.update(cx, |counter, cx: &mut Context<Counter>| {
    // cx is tied to the counter entity
    counter.count += 1;
    cx.notify();
});

Context Type Hierarchy

All context types implement AppContext, but not all have access to advanced features:

Feature	App	VisualContext	Context<T>
Create entities (`cx.new()`)	✅	✅	✅
Global state	✅	✅	✅
Spawn tasks	✅	✅	✅
Open windows	❌	✅	✅
Focus management	❌	✅	✅
`cx.notify()`	❌	❌	✅
`cx.emit()`	❌	❌	✅
`cx.observe()`	❌	❌	✅
`cx.subscribe()`	❌	❌	✅

Common Context APIs

Creating Entities

Available on all contexts:

let counter = cx.new(|cx| Counter { count: 0 });

Accessing Entities

// Read immutably
let value = counter.read(cx).count;

// Update mutably
counter.update(cx, |counter, cx| {
    counter.count += 1;
    cx.notify();
});

Global State

// Define a global
#[derive(Clone, Default)]
struct Theme {
    background: Rgb,
}

impl Global for Theme {}

// Set global (once)
cx.set_global(Theme::default());

// Read global
let theme = Theme::global(cx);

// Update global
cx.update_global::<Theme, _>(|theme, cx| {
    theme.background = rgb(0x1e1e1e);
});

Spawning Async Tasks

// Spawn on UI thread
cx.spawn(|cx| async move {
    // Async work that can access cx
    load_data().await
})

// Spawn on background thread
cx.background_spawn(async move {
    // Heavy computation, no cx access
    compute_something()
})

Entity-Level APIs (Context<T> only)

// Notify observers
cx.notify();

// Emit typed events
cx.emit(MyEvent { data: 42 });

// Observe another entity
cx.observe(&other_entity, |this, cx| {
    // React to changes
}).detach();

// Subscribe to events
cx.subscribe(&other_entity, |this, other, event, cx| {
    // Handle event
}).detach();

// Get handle to self
let self_handle = cx.entity();
let weak_self = cx.weak_entity();

When to Use Which Context

Use App when:

Application startup
Managing top-level state
Creating initial entities

Application::new().run(|cx: &mut App| {
    let app_state = cx.new(|_| AppState::default());
    // Start your app
});

Use VisualContext when:

Opening windows
Working with window-level UI
No specific entity in focus

cx.open_window(WindowOptions::default(), |cx| {
    // cx is VisualContext
    cx.new(|_| RootView::default())
});

Use Context<T> when:

Inside entity methods
Reacting to state changes
Emitting or observing events

impl MyView {
    fn handle_click(&mut self, cx: &mut Context<Self>) {
        self.count += 1;
        cx.notify(); // Only available on Context<T>
    }
}

Window and WindowContext

There’s also ViewContext<T> which is used during rendering:

impl Render for MyView {
    fn render(&mut self, cx: &mut ViewContext<Self>) -> impl IntoElement {
        // cx: a ViewContext<Self> with full entity capabilities
        // window: access to window-specific state via cx.window()
        div().child("Hello")
    }
}

Common Patterns

Pattern 1: Passing Context Down

You can’t store contexts, but you can pass them through function calls:

impl MyView {
    fn build_ui(&mut self, cx: &mut Context<Self>) -> impl IntoElement {
        self.build_header(cx) // Pass cx to helpers
    }

    fn build_header(&mut self, cx: &mut Context<Self>) -> impl IntoElement {
        div().child("Header")
    }
}

Pattern 2: Getting Self Handle

let my_view = cx.new(|cx: &mut Context<MyView>| {
    let self_handle = cx.entity(); // Get handle to entity being created

    // Store it for later or pass to others
    MyView {
        self_ref: self_handle,
    }
});

Pattern 3: Upgrading Context Types

You often receive a less capable context but need a more capable one:

// This won't work - can't upgrade context types directly
// let visual_cx: &mut VisualContext = cx; // ❌

// Instead, you already have the right context type based on where you are:
// - In entity callbacks: Context<T>
// - In window callbacks: VisualContext
// - In app startup: App

Pitfalls

Trying to Store Contexts

// ❌ Bad: Can't store contexts
struct MyView {
    cx: Context<MyView>, // Won't compile
}

// ✅ Good: Contexts are always passed as parameters
impl MyView {
    fn do_something(&mut self, cx: &mut Context<Self>) {
        // Use cx here, don't store it
    }
}

Wrong Context Type

// ❌ Bad: Can't notify from App context
fn update_state(cx: &mut App) {
    cx.notify(); // No such method!
}

// ✅ Good: Use Context<T> for entity operations
fn update_state(cx: &mut Context<MyEntity>) {
    cx.notify(); // Works!
}

Forgetting WeakEntity for Self-References

// ❌ Bad: Strong self-reference creates cycle
let entity = cx.new(|cx| {
    let self_handle = cx.entity();
    MyStruct {
        self_ref: self_handle, // Entity<MyStruct> - cycle!
    }
});

// ✅ Good: Use weak for self-references
let entity = cx.new(|cx| {
    let self_handle = cx.weak_entity();
    MyStruct {
        self_ref: self_handle, // WeakEntity<MyStruct> - no cycle
    }
});

Next Steps

See Views and Rendering to learn how contexts are used in UI
Check State Management for practical context usage patterns
Explore Async Patterns for spawning tasks

Views and Rendering

TODO: This section is a work in progress.

Elements

TODO: This section is a work in progress.

State Management

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Local vs Global State

TODO: This section is a work in progress.

Entity Updates and Notifications

TODO: This section is a work in progress.

Observing State Changes

TODO: This section is a work in progress.

Event Emission

TODO: This section is a work in progress.

Subscriptions

TODO: This section is a work in progress.

UI Components

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Reusable Components

TODO: This section is a work in progress.

Buttons

TODO: This section is a work in progress.

Text Inputs

TODO: This section is a work in progress.

Lists and Tables

TODO: This section is a work in progress.

Modals and Dialogs

TODO: This section is a work in progress.

Menus and Dropdowns

TODO: This section is a work in progress.

Tooltips

TODO: This section is a work in progress.

Layout Patterns

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Common Layouts

TODO: This section is a work in progress.

Flexbox Patterns

TODO: This section is a work in progress.

Grid Layouts

TODO: This section is a work in progress.

Split Panes

TODO: This section is a work in progress.

Tabs

TODO: This section is a work in progress.

Responsive Design

TODO: This section is a work in progress.

Styling Basics

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

The Styled Trait

TODO: This section is a work in progress.

Colors and Backgrounds

TODO: This section is a work in progress.

Spacing and Sizing

TODO: This section is a work in progress.

Borders and Shadows

TODO: This section is a work in progress.

Text Styling

TODO: This section is a work in progress.

Theming

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Building a Theme System

TODO: This section is a work in progress.

Dark/Light Mode

TODO: This section is a work in progress.

Custom Color Palettes

TODO: This section is a work in progress.

Animations

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Basic Animations

TODO: This section is a work in progress.

Transitions

TODO: This section is a work in progress.

Animation Timing

TODO: This section is a work in progress.

Mouse and Touch

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Click Handlers

TODO: This section is a work in progress.

Hover States

TODO: This section is a work in progress.

Drag and Drop

TODO: This section is a work in progress.

Custom Interactions

TODO: This section is a work in progress.

Keyboard Input

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Actions System

TODO: This section is a work in progress.

Keymaps

TODO: This section is a work in progress.

Text Input Handling

TODO: This section is a work in progress.

Focus Management

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Focus Basics

TODO: This section is a work in progress.

Focus Visible

TODO: This section is a work in progress.

Performance

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Render Optimization

TODO: This section is a work in progress.

Efficient Lists

TODO: This section is a work in progress.

Profiling

TODO: This section is a work in progress.

Async and Concurrency

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Spawning Tasks

TODO: This section is a work in progress.

Background Work

TODO: This section is a work in progress.

Async Patterns

TODO: This section is a work in progress.

Custom Elements

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Implementing Element Trait

TODO: This section is a work in progress.

Custom Layout

TODO: This section is a work in progress.

Custom Painting

TODO: This section is a work in progress.

Window Management

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Multiple Windows

TODO: This section is a work in progress.

Window Options

TODO: This section is a work in progress.

Window Events

TODO: This section is a work in progress.

File System

TODO: This section is a work in progress.

Networking

TODO: This section is a work in progress.

Data Persistence

TODO: This section is a work in progress.

External Libraries

TODO: This section is a work in progress.

Recipes

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Building a Counter App

TODO: This section is a work in progress.

Todo List

TODO: This section is a work in progress.

Image Gallery

TODO: This section is a work in progress.

Settings Panel

TODO: This section is a work in progress.

Command Palette

TODO: This section is a work in progress.

Common Mistakes

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Context Lifetime Issues

TODO: This section is a work in progress.

Subscription Management

TODO: This section is a work in progress.

Render Triggers

TODO: This section is a work in progress.

Entity Handle Leaks

TODO: This section is a work in progress.

Best Practices

TODO: This section is a work in progress.

This section covers TODO: add description.

Topics in This Section

TODO: List subsections

Overview

TODO: Provide overview of this topic area

Code Organization

TODO: This section is a work in progress.

Testing GPUI Apps

TODO: This section is a work in progress.

Accessibility

TODO: This section is a work in progress.

Glossary

TODO: This section is a work in progress.

Trait Quick Reference

TODO: This section is a work in progress.

Element Quick Reference

TODO: This section is a work in progress.

Learning Resources

TODO: This section is a work in progress.

Keyboard shortcuts

Unofficial gpui cheat book