How the OpenLogi Component Gallery Enables UI Review Without Config, IPC, or Hardware

The Component Gallery is a debug-only, self-contained gpui application that renders every reusable UI widget using hard-coded mock data, deliberately excluding configuration systems, inter-process communication, and hardware dependencies to provide instant visual feedback during development.

The OpenLogi desktop client manages Logitech hardware through a complex stack involving persistent configurations, background agents, and device I/O. The Component Gallery provides a lightweight alternative for developers who need to iterate on interface components without bootstrapping the entire system. This isolation is achieved through deliberate architectural constraints baked into the gallery's implementation.

Standalone Application Architecture

Unlike the production GUI, which initializes as part of a larger agent-mediated workflow, the Component Gallery launches as an independent gpui application. In crates/openlogi-desktop/src/ui/gallery.rs, the run() function (lines 28–55) creates a fresh application context completely separate from the standard entry flow:

// Inside `run()`: a fresh GPUI app with its own window
let app = gpui_platform::application().with_assets(crate::app_assets::AppAssets);
app.run(|cx| {
    gpui_component::init(cx);
    theme::register_builtin_themes(cx);
    install_openlogi_themes(cx);
    // …
    let opened = cx.open_window(options, |window, cx| {
        theme::apply_scale(window, UiScale::Normal);
        let view = cx.new(ComponentGallery::new);
        cx.new(|cx| Root::new(view, window, cx).bg(cx.theme().background))
    });
    // …
});

This implementation registers built-in themes locally and opens a dedicated window without invoking the IPC agent initialization sequence found in the main application binary.

Eliminating External Dependencies

The gallery enforces strict isolation through three deliberate exclusion patterns that prevent runtime complexity from bleeding into the UI review process.

No Configuration Loading

The gallery never imports openlogi_core::config or openlogi_core::state. All visual state—including theme selection (Light/Dark) and UI scaling (Normal/Compact)—is controlled through local button callbacks that mutate the in-memory ComponentGallery struct. The toolbar caption at lines 30–36 explicitly documents this constraint: "Debug-only · no config, IPC, or hardware".

No IPC Communication

While the production GUI communicates with the background agent via openlogi-ipc tarpc contracts, the gallery contains no IPC module imports. All interactions use local cx.listener callbacks rather than remote procedure calls. This means no channel initialization, no agent handshake, and no message serialization overhead when interacting with gallery controls.

No Hardware Interaction

Widgets that normally reflect physical device state receive synthetic data structures instead. The BatteryIndicator component renders BatteryInfo structs constructed with fixed percentages and statuses, eliminating HID++ enumeration and battery polling. This ensures developers can review battery level visuals (Good, Low, Critical) without connecting physical devices.

Hard-Coded UI State Implementation

Every interactive element in the gallery uses static data to ensure deterministic rendering. For example, the battery demonstration panel constructs mock power states programmatically:

// Mock battery data – no real hardware queried
let battery = |percentage, level, status| BatteryInfo {
    percentage,
    level,
    status,
};
gallery_panel(
    "BatteryIndicator",
    IconName::Battery,
    v_flex()
        .gap_3()
        .child(BatteryIndicator::summary(&battery(78, BatteryLevel::Good, BatteryStatus::Discharging)))
        .child(BatteryIndicator::status(&battery(100, BatteryLevel::Full, BatteryStatus::Full), true))
        // …
);

Similarly, the device carousel displays placeholder cards rather than real device profiles, and profile tabs render with hard-coded labels rather than querying the onboard memory of attached peripherals.

Launching the Isolated Gallery

Developers invoke this sandbox environment through a simple Cargo command that bypasses the full application stack:

# Launching the isolated gallery (run from the repository root)

cargo run -p openlogi-desktop

The entry point in crates/openlogi-desktop/src/main.rs (lines 66–68) calls ui::gallery::run() unconditionally when the binary executes, ensuring the gallery launches instantly without initializing configuration parsers, IPC channels, or hardware managers.

Summary

• The Component Gallery resides in crates/openlogi-desktop/src/ui/gallery.rs as a debug-only tool
• It operates as a standalone gpui application with its own window context and local event loop
• All widget data is hard-coded; the system never reads openlogi_core::config, opens openlogi-ipc channels, or queries HID devices
• Launch via cargo run -p openlogi-desktop for immediate UI iteration without hardware dependencies

Frequently Asked Questions

What is the Component Gallery in OpenLogi?

The Component Gallery is a specialized debugging interface that renders reusable UI widgets—including toggles, menus, battery indicators, and carousels—in complete isolation from the production application stack. It serves as a visual regression testing ground and design reference implementation.

How does the gallery avoid loading configuration files?

The implementation deliberately excludes imports from openlogi_core::config and openlogi_core::state. Theme selection and scaling preferences exist only as local state within the ComponentGallery struct, ensuring no persistent storage reads occur during UI review.

Can the Component Gallery interact with Logitech hardware?

No. The gallery uses mock BatteryInfo structs and placeholder device profiles rather than querying physical peripherals. No HID++ enumeration, battery polling, or device I/O occurs, making it safe to run without any Logitech hardware connected.

How do I launch the Component Gallery during development?

Execute cargo run -p openlogi-desktop from the repository root. The binary's entry point in crates/openlogi-desktop/src/main.rs automatically routes to ui::gallery::run(), bypassing the standard agent initialization and presenting the isolated UI immediately.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}