Create GUI Component

Standardize wxPython Panels and Dialogs with event-driven architecture.

Updated Jan 21, 2026
One-click install
npx skills add https://github.com/Row0902/agents --skill create-gui-component
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Create GUI Component
Source: https://github.com/Row0902/agents/tree/main/.agent/skills/create_gui_component
Command: npx skills add https://github.com/Row0902/agents --skill create-gui-component

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Helps developers create clean, decoupled wxPython UI components by standardizing Panels and Dialogs.

Core Features & Use Cases

  • Standard Panel structure: Always inherit from wx.Panel. never put business logic directly here. Use EventBus to talk to services.
  • Dialog standard: Use wx.Dialog with standard buttons.
  • Checklist: No logic in _on_event methods? (Publish events instead). Used BoxSizer or GridBagSizer? (No absolute positioning). All user-visible strings in English?

Quick Start

Create a new wx.Panel subclass, implement UI in a dedicated _init_ui method using a Master Sizer, and publish actions via EventBus instead of calling services directly.

Frequently Asked Questions about Create GUI Component

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

FAQPage Schema
How do I create decoupled wxPython panels and dialogs?

Standardizing wxPython panels involves inheriting from wx.Panel, keeping business logic out, and using EventBus to communicate with services. Dialogs should use wx.Dialog with standard buttons and BoxSizer or GridBagSizer layouts.

Why should I use an EventBus in wxPython UI components?

Using an EventBus in wxPython UI components enforces decoupled architecture by letting panels publish events instead of calling services directly. This keeps _on_event methods free of business logic and maintains clean separation between UI and service layers.

What is the best way to structure a wxPython Panel to avoid mixing UI and business logic?

The best way to structure a wxPython Panel is to inherit from wx.Panel, implement all UI in a _init_ui method with a Master Sizer, and ensure _on_event methods only publish events via EventBus rather than executing business logic directly.

Can I use absolute positioning in standardized wxPython dialogs?

No, standardized wxPython dialogs should not use absolute positioning. The checklist enforces using BoxSizer or GridBagSizer for layout instead, ensuring dialogs built with wx.Dialog and standard buttons remain consistent and resizable.

Does this approach work for large wxPython desktop apps with many reusable panels?

Yes, this approach suits wxPython desktop apps where reusable, decoupled UI components are needed across panels and dialogs. The standard Panel structure and event-driven EventBus architecture scale across multiple components without tight coupling.

What layout sizers should I use for standardized wxPython components?

For standardized wxPython components, you should use BoxSizer or GridBagSizer for layout. The checklist explicitly prohibits absolute positioning, requiring these sizers to manage UI layout within the Master Sizer in your _init_ui method.