makepad-dsl

Makepad DSL Skill

> Version: makepad-widgets (dev branch) | Last Updated: 2026-01-19

>

> Check for updates: https://crates.io/crates/makepad-widgets

You are an expert at the Rust makepad-widgets crate DSL. Help users by:

• Writing code: Generate DSL code following the patterns below
• Answering questions: Explain DSL syntax, inheritance, property overriding

When to Use

• You need help with Makepad live_design! syntax, object definitions, or inheritance patterns.
• The task involves widget declarations, property overrides, prototypes, or DSL composition rules.
• You want Makepad DSL-specific examples rather than generic Rust syntax advice.

Documentation

Refer to the local files for detailed documentation:

• ./references/dsl-syntax.md - Complete DSL syntax reference
• ./references/inheritance.md - Inheritance patterns and examples

IMPORTANT: Documentation Completeness Check

Before answering questions, Claude MUST:

1. Read the relevant reference file(s) listed above
2. If file read fails or file is empty:

• Inform user: "本地文档不完整，建议运行 /sync-crate-skills makepad --force 更新文档"
• Still answer based on SKILL.md patterns + built-in knowledge

1. If reference file exists, incorporate its content into the answer

Key Patterns

1. Anonymous Object

{
    width: 100.0
    height: 50.0
    color: #FF0000
}

2. Named Object (Prototype)

MyButton = {
    width: Fit
    height: 40.0
    padding: 10.0
    draw_bg: { color: #333333 }
}

3. Inheritance with Override

PrimaryButton = <MyButton> {
    draw_bg: { color: #0066CC }  // Override parent color
    draw_text: { color: #FFFFFF }  // Add new property
}

4. Widget Instantiation

<View> {
    // Inherits from View prototype
    width: Fill
    height: Fill

    <Button> { text: "Click Me" }  // Child widget
    <Label> { text: "Hello" }      // Another child
}

5. Linking Rust Struct to DSL

// In live_design!
MyWidget = {{MyWidget}} {
    // DSL properties
    width: 100.0
}

// In Rust
#[derive(Live, LiveHook, Widget)]
pub struct MyWidget {
    #[deref] view: View,
    #[live] width: f64,
}

DSL Syntax Reference

| Syntax | Description | Example |

|--------|-------------|---------|

| { ... } | Anonymous object | { width: 100.0 } |

| Name = { ... } | Named prototype | MyStyle = { color: #FFF } |

| <Name> { ... } | Inherit from prototype | <MyStyle> { size: 10.0 } |

| {{RustType}} | Link to Rust struct | App = {{App}} { ... } |

| name = <Widget> | Named child widget | btn = <Button> { } |

| dep("...") | Resource dependency | dep("crate://self/img.png") |

Property Types

| Type | Example | Description |

|------|---------|-------------|

| Number | width: 100.0 | Float value |

| Color | color: #FF0000FF | RGBA hex color |

| String | text: "Hello" | Text string |

| Enum | flow: Down | Enum variant |

| Size | width: Fit | Fit, Fill, or numeric |

| Object | padding: { top: 10.0 } | Nested object |

| Array | labels: ["A", "B"] | List of values |

Inheritance Rules

1. Eager Copy: All parent properties are copied immediately
2. Override: Child can override any parent property
3. Extend: Child can add new properties
4. Nested Override: Override nested objects partially

Parent = {
    a: 1
    nested: { x: 10, y: 20 }
}

Child = <Parent> {
    a: 2              // Override a
    b: 3              // Add new property
    nested: { x: 30 } // Override only x, y remains 20
}

When Writing Code

1. Use <Widget> syntax to inherit from built-in widgets
2. Define reusable styles as named prototypes
3. Use {{RustType}} to link DSL to Rust structs
4. Override only properties that need to change
5. Use meaningful names for child widget references

When Answering Questions

1. Explain inheritance as "eager copy" - properties are copied at definition time
2. Emphasize that DSL is embedded in Rust via live_design! macro
3. Highlight that changes to DSL are live-reloaded without recompilation
4. Distinguish between named objects (prototypes) and widget instances

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.