gpui-element

Implement custom GPUI elements via the low-level Element API lifecycle.

12.5k|757|Updated Jun 13, 2024
One-click install
npx skills add https://github.com/longbridge/gpui-component --skill gpui-element-longbridge
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: gpui-element
Source: https://github.com/longbridge/gpui-component/tree/main/.claude/skills/gpui-element
Command: npx skills add https://github.com/longbridge/gpui-component --skill gpui-element-longbridge

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Implementing custom elements using GPUI's low-level Element API (vs. high-level Render/RenderOnce APIs). Use when you need maximum control over layout, prepaint, and paint phases for complex, performance-critical custom UI components that cannot be achieved with Render/RenderOnce traits.

Core Features & Use Cases

  • Direct control over request_layout, prepaint, and paint phases for maximum performance and customization.
  • Supports advanced patterns (e.g., Masonry, Circular layouts) and reusable element behavior via traits for composition.
  • Suitable for building interactive and scrollable containers with precise hitbox handling and custom event logic.

Quick Start

Define a new Element by creating a struct, implement Element for it with RequestLayoutState and PrepaintState, and wire up request_layout, prepaint, and paint through the Window/App context.

Frequently Asked Questions about gpui-element

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create custom UI components in GPUI when Render traits are not enough?

To create a custom GPUI element, define a struct, implement the Element trait with its associated RequestLayoutState and PrepaintState, then wire up request_layout, prepaint, and paint functions through the Window or App context.

When do I need to use the low-level Element API instead of RenderOnce?

The GPUI Element trait lifecycle requires three phases: request_layout for measuring, prepaint for positioning and hitbox registration, and paint for rendering, with associated state types passed between them to support advanced usage.

Can I build masonry layouts and circular arrangements using GPUI elements?

Yes, you can build interactive and scrollable GPUI containers with precise hitbox handling by implementing custom event logic within the prepaint phase of the low-level Element API.

What's the best way to handle hitbox-driven interactions in a GPUI scrollable container?

Do not use GPUI's low-level Element API for standard UI components, as it introduces unnecessary complexity compared to Render or RenderOnce traits; reserve it for performance-critical custom layouts requiring direct phase control.