https://github.com/yhyzgn/liora

Pure Rust + GPUI native enterprise UI component library for desktop apps — Element Plus-inspired components, charts, docs, tray integration, and installer packaging.
https://github.com/yhyzgn/liora
charts code-editor component-library cross-platform dark-theme desktop-app element-plus enterprise-ui gpui gui installer markdown-renderer native-desktop native-ui packaging rust rust-desktop rust-ui system-tray ui-components
Last synced: about 17 hours ago
JSON representation
Pure Rust + GPUI native enterprise UI component library for desktop apps — Element Plus-inspired components, charts, docs, tray integration, and installer packaging.
Host: GitHub
URL: https://github.com/yhyzgn/liora
Owner: yhyzgn
License: other
Created: 2026-05-03T09:03:36.000Z (about 2 months ago)
Default Branch: main
Last Pushed: 2026-06-26T03:00:51.000Z (1 day ago)
Last Synced: 2026-06-26T03:12:35.639Z (1 day ago)
Topics: charts, code-editor, component-library, cross-platform, dark-theme, desktop-app, element-plus, enterprise-ui, gpui, gui, installer, markdown-renderer, native-desktop, native-ui, packaging, rust, rust-desktop, rust-ui, system-tray, ui-components
Language: Rust
Homepage: https://github.com/yhyzgn/liora
Size: 21.4 MB
Stars: 2
Watchers: 0
Forks: 0
Open Issues: 1
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- Contributing: CONTRIBUTING.md
- License: LICENSE.md
- Agents: AGENTS.md
Awesome Lists containing this project

README

          


  

    

    

  

  
Enterprise-grade native UI components for Rust desktop applications.

  Pure Rust. GPUI native. Element Plus-inspired APIs. No Tauri, no WebView, no browser runtime.


  


    简体中文

    ·

    Contributing

    ·

    Changelog

  


  


    

    

    

    

    

  



---

## What is Liora?

**Liora** is a monorepo for building polished, enterprise-style **Rust native desktop UI** with [GPUI](https://github.com/zed-industries/zed). It brings a broad Element Plus-inspired component taxonomy to native Rust applications: basic elements, forms, overlays, navigation, data display, advanced inputs, native charts, virtualized data views, code display/editing, tray integration, and installer packaging infrastructure.

Liora is intentionally not a web shell. Applications built with Liora stay on the **pure Rust + GPUI native** path:

- no Tauri runtime;

- no WebView, HTML/CSS/DOM, or browser application shell;

- no web chart runtime, SVG DOM charting layer, or frontend build pipeline;

- Gallery and Docs are native GPUI applications that demonstrate the library in real app shells.

## Why Liora?

Rust desktop teams often need more than a handful of primitives. Liora focuses on the missing middle between low-level GPUI layout code and real product screens:

| Need | Liora answer |

|---|---|

| Native desktop UI | GPUI element trees, native windows, native text/layout/paint paths. |

| Enterprise component coverage | Element Plus-style categories and APIs across forms, feedback, data, navigation, charts, and advanced controls. |

| Real app surfaces | `liora-gallery` and `liora-docs` show complete native application setup, theme switching, search/filtering, tray behavior, docs rendering, and dashboard-style composition. |

| Theming | Light, Dark, and System theme modes with semantic tokens and component-level variants. |

| One dependency for apps | `cargo add liora` exposes the maintained SDK facade: core, theme, components, icons, tray, packaging, and generic updater helpers. |

| Native distribution | `liora-packager` + `xtask package` validate installer information, manifests, checksums, signing policy, and package generation plans. |

| Clear architecture boundary | Reusable components stay in `liora-components`; product-specific data models and screen composition stay in applications. |

## Feature highlights

- **One-stop SDK facade**: depend on `liora` for application development, or use focused crates such as `liora-components`, `liora-theme`, and `liora-packager` when you need narrower surfaces.

- **70+ native UI components** across Basic, Form, Feedback, Data, Navigation, and Others categories.

- **Element Plus-inspired API style** adapted for Rust builders and GPUI rendering.

- **Native charting**: Line, Area, Bar, Pie, Ring, Sparkline, scales, grids, legends, downsampling, and hover hit testing.

- **Advanced controls**: CodeEditor, CodeBlock, QR code, Timer, SignalMeter, HeatBar, SegmentRatioBar, draggable lists, Tour, TreeSelect, Mention, InputTag, Watermark, virtualized table/tree.

- **Overlay and interaction systems**: Tooltip, Popover, Popconfirm, Dialog, Drawer, Dropdown, Message, Notification, MessageBox, Loading, Preview, Tour.

- **Native docs renderer**: Markdown is parsed as input and rendered into Liora/GPUI native nodes; code snippets live outside Markdown and are compile-checked.

- **System tray facade**: `liora-tray` wraps `tray-icon` + `muda` for dynamic icons, nested menus, checkbox items, stable commands, and process-resident GPUI apps.

- **Installer pipeline**: package information validation, `cargo-packager` config generation, RPM supplemental config, portable `.tar.gz`, manifests, checksums, release notes, and CI validation gates.

- **Reusable updater pipeline**: `liora-updater` checks GitHub Releases for any configured repository, selects assets with app/platform naming rules, downloads into a cache, verifies SHA-256 manifests, and returns an explicit install plan. Liora Gallery/Docs use small built-in presets on top of the generic API.

- **Quality gates**: workspace fmt/check/test, docs snippet checks, package validation, release-readiness checks, and GUI startup smoke commands.

## Component coverage

| Category | Components and capabilities |

|---|---|

| Basic | Button, ButtonGroup, Icon, Link, Text, Title, Paragraph, Space, Divider, Row, Col, Container, Scrollbar, Splitter, CodeBlock |

| Form | Input, InputNumber, Textarea, Checkbox, CheckboxGroup, Radio, RadioGroup, Switch, Select, Slider, Form, FormItem, Rate, DatePicker, TimePicker, DateTimePicker, Upload, Cascader, Transfer, ColorPicker, Autocomplete, InputTag, Mention, TreeSelect |

| Feedback / Overlay | Tooltip, Popover, Popconfirm, Dialog, Drawer, Message, Notification, Alert, Loading, MessageBox, Dropdown, Card, Collapse, Preview, Tour |

| Navigation | Menu, Tabs, Breadcrumb, Steps, PageHeader, Affix, Backtop, Anchor |

| Data display | Table, VirtualizedTable, VirtualizedTree, VirtualizedList, Progress, Skeleton, Empty, Result, Descriptions, Timeline, Tree, Pagination, Statistic, Segmented, Tag, Avatar, Badge, Calendar, Carousel, Image, Watermark |

| Charts / Metrics | LineChart, AreaChart, BarChart, PieChart, RingChart, Sparkline, SignalMeter, HeatBar, SegmentRatioBar |

| Editing / Utility | CodeEditor, QrCode, Timer, Label, Operation, draggable horizontal and vertical list patterns |

| Platform / App shell | `liora-tray`, custom window frame, Gallery shell composition, Docs adoption pages, packaging helpers |

## Repository layout

```text

liora/

├── crates/

│   ├── liora/                 # one-stop SDK facade for application dependencies

│   ├── liora-core/            # global config, theme setup, popper/portal state, unique IDs

│   ├── liora-theme/           # semantic tokens, light/dark/system theme support

│   ├── liora-components/      # reusable GPUI components

│   ├── liora-icons/           # native icon trait and helpers

│   ├── liora-icons-lucide/    # generated Lucide icon names and paths

│   ├── liora-tray/            # tray-icon + muda facade for GPUI apps

│   ├── liora-packager/        # package info, manifests, checksums, backend config

│   └── liora-updater/         # GitHub Release checks, downloads, checksums, install plans

├── apps/

│   ├── liora-gallery/         # native component gallery and showcase application

│   └── liora-docs/            # native documentation app and Markdown renderer

├── xtask/                     # cargo run -p xtask -- package ...

├── packaging/                 # icons, desktop/metainfo, macOS/Windows/Linux package resources

└── Cargo.toml                 # workspace root

```

## Quick start

### 1. Install prerequisites

Install Rust stable and the native dependencies required by GPUI on your platform. On Linux, common development packages include GTK3, Wayland/X11, xkbcommon, fontconfig/freetype, Vulkan, ALSA, and `pkg-config`. The repository also includes `scripts/install-fedora-deps.sh` for Fedora-oriented setup.

### 2. Add Liora to an app

```bash

cargo add liora

```

Use lower-level crates such as `liora-components` or `liora-packager` only when a workspace needs a narrower dependency surface.

### Updater module

`liora-updater` is included in the default `liora` facade and can also be used directly:

```bash

cargo add liora-updater

```

It provides a reusable GitHub Release update layer for your own applications: configure the owner/repo, current tag, app name, platform selector, cache directory, checksum asset name, and installer preference. Gallery and Docs use Liora presets, but those presets are not required for other products.

```rust

use liora_updater::{

    AssetKind, AssetSelector, Platform, UpdateRequest, Updater,

};

let platform = Platform::current().expect("supported desktop platform");

let request = UpdateRequest::new(

    "acme-notes",

    "v0.3.0",

    platform,

    std::env::temp_dir().join("acme-notes-updates"),

)

.selector(

    AssetSelector::for_platform(platform)

        .matching_prefix("acme-notes")

        .kind_priority([AssetKind::Installer, AssetKind::RawExecutable]),

);

if let Some(update) = Updater::new("acme", "acme-notes")

    .with_checksum_asset_name("SHA256SUMS.txt")

    .prepare_update(&request)?

{

    // Show update.release_tag(), update.asset.name, and update.install_plan in your UI.

    // Run update.install_plan.install() only from an explicit user action.

}

# Ok::<(), liora_updater::UpdaterError>(())

```

The updater can automatically check, download, and verify assets, while installation remains a visible user action because some installer formats require OS elevation or replacing a running executable.

### 3. Run the native Gallery

```bash

cargo run -p liora-gallery

```

The Gallery presents component demos, theme switching, search/filtering, tray controls, toasts, and product-style composition in a native GPUI window.

### 4. Run the native Docs app

```bash

cargo run -p liora-docs

```

The Docs app explains adoption and component usage. It renders Markdown content into native Liora/GPUI elements and shows compile-checked snippets from `apps/liora-docs/content/snippets/`.

### 5. Check the workspace

```bash

cargo fmt --all --check

cargo check --workspace --all-targets

cargo test --workspace

cargo check -p liora-docs --bin check_snippets

cargo doc --workspace --no-deps

```

## Minimal application shape

A Liora-powered GPUI app should initialize theme/config, initialize global services used by selected components, register component key bindings, and then open a GPUI window.

```rust

use gpui::{App, Application};

use liora::init_liora;

fn main() {

    Application::new().run(|cx: &mut App| {

        // Initializes Liora core/theme state, component services, and key bindings.

        init_liora(cx);

        // cx.open_window(...)

    });

}

```

`liora::init_liora(cx)` follows the operating system by default and also initializes component services plus key bindings. Use `liora::init_liora_with_mode(cx, ThemeMode::Light | ThemeMode::Dark | ThemeMode::System)` when a product wants to choose the startup mode explicitly. The lower-level `liora_components::init_liora(...)` entry point remains available for users who depend on individual crates instead of the facade. Use `Entity` for stateful controls such as `Input`, `Switch`, `Select`, and `CodeEditor` so focus and internal state survive re-rendering. Gallery and Docs are compile-checked references for app shell setup, key binding registration, theme switching, tray behavior, toasts, and composition patterns.

## Component API example

Liora components follow a builder style and render through GPUI-native elements:

```rust

use gpui::{div, IntoElement, RenderOnce};

use liora::components::{Button, Space, Tag, Text, Title};

struct WelcomePanel;

impl RenderOnce for WelcomePanel {

    fn render(self, _window: &mut gpui::Window, _cx: &mut gpui::App) -> impl IntoElement {

        div()

            .child(Title::new("Native Rust UI").level(2))

            .child(Text::new("Build enterprise desktop screens with GPUI and Liora."))

            .child(

                Space::new()

                    .child(Button::new("Open Gallery").primary())

                    .child(Tag::new("Pure Rust").success()),

            )

    }

}

```

Themes are read from Liora global config inside render paths. Avoid passing theme objects through `.build(theme)`-style APIs.

## Technical differentiators

Liora is more than a component catalog:

- **One-dependency adoption**: `liora` re-exports the maintained public SDK modules so app manifests stay compact while focused crates remain independently usable.

- **One-call application setup**: `init_liora(cx)` centralizes core configuration, component services, and keyboard bindings so applications do not repeat per-widget setup.

- **Native Markdown documentation**: Markdown stays as authored content, while the running Docs app renders it into Liora/GPUI nodes and verifies external Rust snippets.

- **Native charts without a browser layer**: chart primitives use Rust data structures, GPUI paint paths, hit testing, and downsampling instead of a WebView chart runtime.

- **Application-shell coverage**: tray residency, toasts, theme switching, searchable component navigation, and dashboard-style layouts are exercised in real native apps.

- **Packaging-aware from the workspace**: installer information, manifests, checksums, backend configs, and dry-run install plans are validated alongside code.

## Documentation map

| Resource | Purpose |

|---|---|

| `apps/liora-docs` | Native documentation app, adoption guide, component pages, and compile-checked snippets. |

| `apps/liora-gallery` | Native component Gallery and app-shell reference surface. |

| `apps/liora-docs/content/pages/` | Markdown source pages rendered by the native Docs app. |

| `apps/liora-docs/content/snippets/` | External code snippets referenced by Markdown and checked by `check_snippets`. |

## GPUI dependency and local patch policy

Published Liora SDK crates depend directly on the official Zed crates.io package `gpui = "0.2.2"` (`repository = "https://github.com/zed-industries/zed"`). They must not use renamed or community forks, and they must not vendor, publish, or force the local `third_party/zed` patch.

Gallery and Docs build the same way by default: official crates.io `gpui`, with platform features enabled only in the final app crates. The repository keeps `third_party/zed` only as non-published upstream-source reference material for the Linux startup-window patch discussion. If you need to verify that local patch, do it on a throwaway branch and apply it only at an application root:

```toml

[patch.crates-io]

gpui = { path = "third_party/zed/crates/gpui" }

```

Do not commit that override to publishable Liora crate manifests, and do not publish Liora crates with any `[patch]` section or path GPUI dependency. Downstream products should also stay on official Zed `gpui` unless they deliberately own an application-level upstream-source verification branch.

## Native packaging

Repository-owned packaging readiness is implemented through the published `liora-packager` library plus the repository-local `xtask` command wrapper:

```bash

cargo run -p xtask -- package validate

cargo run -p xtask -- package release-readiness

cargo run -p xtask -- package ci --all-apps --format platform-defaults --dry-run --skip-build

cargo run -p xtask -- package install-smoke --all-apps --format platform-defaults --dry-run

```

The packaging pipeline can generate backend config for AppImage, `.deb`, `.rpm`, macOS `.app` / `.dmg`, Windows NSIS / MSI, and Liora portable `.tar.gz` archives. Signing, notarization, installer smoke tests, and publication are intentionally separated from everyday development commands so application code remains pure Rust + GPUI native.

## Quality gates

Before publishing or submitting changes, run the same local checks used by the project:

```bash

cargo fmt --all --check

cargo check --workspace --all-targets

cargo test --workspace

cargo check -p liora-docs --bin check_snippets

cargo doc --workspace --no-deps

cargo run -p xtask -- package validate

cargo run -p xtask -- package ci --all-apps --format platform-defaults --dry-run --skip-build

```

Component changes should include the reusable component API, Gallery coverage, native Docs content, external snippets, and focused tests for calculations or interaction behavior.

## Design principles

Liora is designed around a few product-facing rules:

- **Native first**: every component renders through GPUI element trees, native text, native input, and native paint paths.

- **Application-ready defaults**: theme, overlay, message, keyboard, and selection behavior should work from one setup call.

- **Composable over prescriptive**: components expose builder-style APIs and stay reusable; product screens and data models belong in applications.

- **Token-driven visuals**: light/dark/system themes use semantic tokens for surfaces, text, borders, masks, and interaction states.

- **Performance-aware data UI**: charts and virtualized views include downsampling, hit testing, cache limits, and visible-area rendering patterns.

## Runtime model

`liora::init_liora(cx)` is the recommended application entry point when using the facade crate. `liora_components::init_liora(cx)` provides the same setup for users of the focused components crate. It initializes Liora core/theme state, global component services, and key bindings for interactive controls.

Use `liora::init_liora_with_mode(cx, ThemeMode::Light | ThemeMode::Dark | ThemeMode::System)` when the product needs to choose an explicit startup theme mode. Runtime theme switches still use `apply_theme_mode(window, cx, mode)` from `liora_core`.

Stateful controls such as `Input`, `Switch`, `Select`, and `CodeEditor` should live in `gpui::Entity` fields so focus, open state, selections, and text values survive re-rendering.

## Contributing

Read `CONTRIBUTING.md` before opening a pull request. Important boundaries:

- Keep Liora pure Rust + GPUI native.

- Do not introduce Tauri, WebView, HTML/CSS/DOM, browser runtime, or web chart shells.

- Do not re-add standalone `examples/minimal-app` or `examples/dashboard-app`.

- Keep product-specific data models and screen-level helper code out of `liora-components`.

## License

Liora currently uses `LicenseRef-Liora`; see `LICENSE.md`. Do not assume an OSS license until the project maintainer replaces that policy with explicit OSS or commercial terms.
ecosyste.ms

Data

Tools

Indexes

Applications

Experiments

Awesome

https://github.com/yhyzgn/liora

Awesome Lists containing this project

README
