WAIT — Stale — last commit 4y ago

• 6 active contributors
• MIT licensed
• CI configured
• ⚠ Stale — last commit 4y ago
• ⚠ Single-maintainer risk — top contributor 81% of recent commits
• ⚠ No test directory detected
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

OrbTk is a cross-platform Rust GUI toolkit built on the Entity Component System (ECS) pattern, providing a functional reactive API for building scalable user interfaces. It powers UI applications on Redox OS and supports macOS, Linux, and other platforms via renderers like orbclient and tinyskia, enabling developers to write once and deploy across multiple operating systems. Monorepo with 7 workspace members in Cargo.toml: orbtk/ (main facade), orbtk_core (ECS engine), orbtk_widgets (UI components), orbtk_orbclient (Redox renderer), orbtk_tinyskia (raster backend), proc_macros (derive macros), and utils (helpers). Examples in orbtk/examples/ (calculator.rs, showcase.rs, login.rs, etc.) demonstrate the API; theme assets in orbtk/examples/assets/ use RON format for dark/light modes and i18n (de_DE locales present).

Rust systems programmers and Redox OS application developers who need a lightweight, ECS-based UI framework; developers prioritizing cross-platform compatibility and functional reactive patterns over feature richness. The project was primarily maintained by @FloVanGH, @rzerres, and @jackpot51, though it is now sunsetting in favor of iced and slint.

OrbTk is in sunset/maintenance mode as of the README announcement—the original creator moved to iced, core maintainers transitioned to slint. The codebase is stable at 0.3.1-alpha4 (visible on crates.io and docs.rs) with CI/CD via GitHub Actions (orbtk.yml), but no active feature development is occurring. This is a stable but no-longer-evolving project suitable for existing Redox OS applications, not new projects.

Critical risk: sunsetting status means no security patches or bug fixes are planned. Dependency quality concerns: the monorepo spans 7 crates (orbtk_core, orbtk_widgets, orbtk_orbclient, orbtk_tinyskia, proc_macros, utils) with no visible lock file in the listing, creating upgrade fragility. Single-maintainer legacy risk is high—@rzerres was the sole active maintainer before sunset. Breaking changes between 0.2→0.3 (noted in README) indicate the API is not stable.

No active development—the repository is in sunset maintenance. The last significant work was modernization between 0.2→0.3 by @FloVanGH and feature additions by @rzerres. The CHANGELOG.md and workflow (orbtk.yml) suggest the CI still runs, but no PRs or active issues are visible in the file structure.

git clone https://github.com/redox-os/orbtk.git
cd orbtk
cargo build --workspace
cargo run --example minimal --release

Optional: inspect Cargo.toml at the root to see workspace members; run cargo run --example showcase for a feature-rich demo.

Daily commands:

cargo build --release
cargo run --example calculator --release
cargo run --example showcase --release
cargo run --example minimal --release

Dev builds available with cargo run --example <name> (slower, debuggable). See orbtk/examples/README.md for example descriptions.

• orbtk/src/lib.rs — Main crate entry point that re-exports the public API and prelude; all external consumers start here.
• orbtk/src/application.rs — Core application lifecycle and window management; defines how the UI toolkit bootstraps and runs event loops.
• orbtk_core/src/lib.rs — Foundation crate providing the event system, layout engine, and property system that all widgets depend on.
• orbtk_core/src/event/mod.rs — Event routing and handling infrastructure; critical for understanding how user input flows through the toolkit.
• orbtk_core/src/layout/mod.rs — Layout constraint system (absolute, grid, stack, padding); determines how widgets are positioned and sized.
• orbtk_core/src/application/mod.rs — Application context and window management; coordinates rendering, event dispatch, and state across all windows.
• Cargo.toml — Workspace root defining all member crates (orbtk, orbtk_core, orbtk_widgets, orbtk_orbclient, orbtk_tinyskia) and shared dependencies.

Add a Custom Widget

1. Create a new file in orbtk_widgets crate with widget struct implementing the Widget trait. (orbtk_widgets/src/widgets/my_widget.rs)
2. Define properties using the widget! macro in the same file; inherits from Block layout properties. (orbtk_widgets/src/widgets/my_widget.rs)
3. Register the widget in the module exports (orbtk_widgets/src/lib.rs or widgets/mod.rs). (orbtk_widgets/src/lib.rs)
4. Implement event handlers by matching on Event types in the impl block; use ctx to dispatch actions. (orbtk_widgets/src/widgets/my_widget.rs)
5. Create an example in orbtk/examples/ to demonstrate usage and test in the showcase. (orbtk/examples/showcase.rs)

Add a New Layout Type

1. Create a new file in orbtk_core/src/layout/ (e.g., flow.rs) and implement the Layout trait. (orbtk_core/src/layout/flow.rs)
2. Implement the layout logic in the arrange() method; read parent constraints and position children. (orbtk_core/src/layout/flow.rs)
3. Export the layout in orbtk_core/src/layout/mod.rs and add it to the Layout enum or trait object. (orbtk_core/src/layout/mod.rs)
4. Define layout-specific properties in orbtk_core/src/properties/layout/ if needed. (orbtk_core/src/properties/layout/mod.rs)
5. Add a test example in orbtk/examples/ to validate layout behavior. (orbtk/examples/stack.rs)

Add Multi-Language Support (New Locale)

1. Create a new RON translation file in orbtk/examples/assets/ named with locale code (e.g., showcase_fr_FR.ron). (orbtk/examples/assets/showcase/showcase_fr_FR.ron)
2. Follow the dictionary structure from existing locales; use the same keys mapped to translated strings. (orbtk/examples/assets/showcase/showcase_de_DE.ron)
3. Load the localization in your app by calling RonLocalization::load() with the file path. (orbtk/examples/showcase.rs)
4. Retrieve translations in widgets using ctx.localization().get(key, default). (orbtk_core/src/localization/mod.rs)

Handle Custom Events in an Application

1. Define your custom event enum or struct; ensure it fits into the toolkit's Event system. (orbtk/examples/msg_handler.rs)
2. Create an event handler in your widget by implementing the on_event() method; match Event variants. (orbtk/examples/msg_handler.rs)
3. Use ctx.send_message() or ctx.send_action() to dispatch custom messages between widgets. (orbtk_core/src/event/event_handler.rs)
4. In the application's event loop or widget handler, respond to dispatched messages; update state reactively. (orbtk/examples/msg_handler.rs)

• Rust — Memory safety, zero-cost abstractions, and performance critical for cross-platform UI rendering; enables safe concurrent event handling and property binding.
• Trait-based architecture (Layout, Widget, Event traits) — Enables pluggable layouts, custom widgets, and extensible event handling without tight coupling; supports multiple backend renderers (orbclient, tinyskia).
• RON (Rusty Object Notation) for theming & localization — Human-readable, Rust-native serialization format; avoids JSON/XML verbosity and integrates cleanly with Rust's type system.
• Procedural mac — undefined

1. Sunsetting status: fixes and features will not be merged; use for maintenance of existing apps only. 2. RON asset format: theme and config files use RON (Rusty Object Notation)—not JSON or TOML; parser errors are easy to miss. 3. Workspace feature flags: some crates expose optional features (e.g., different renderers) that must be enabled in Cargo.toml—check individual Cargo.toml for feature_tree. 4. ECS learning curve: the API is functional-reactive; understanding Entity, Component, and System abstractions is mandatory. 5. Platform support: orbclient renderer ties tightly to Redox OS syscalls; non-Redox development requires tinyskia or custom backends.

• Entity Component System (ECS) — OrbTk's core architectural pattern—understanding entities (UI elements), components (properties/state), and systems (update logic) is essential to building or extending widgets
• Functional Reactive Programming (FRP) — OrbTk's API uses FRP-like event handling; understanding streams, observables, and declarative event binding is crucial for writing reactive UIs
• Renderer abstraction (orbclient vs. tinyskia) — OrbTk supports multiple rendering backends; knowing when to use orbclient (Redox-native) versus tinyskia (cross-platform raster) affects portability and performance
• RON (Rusty Object Notation) — OrbTk uses RON for all theme and localization assets (showcase_de_DE.ron, calculator_dark.ron); syntax errors here are silent and hard to debug
• Procedural macros for widget definition — The proc_macros/ crate enables ergonomic widget syntax; understanding macro expansion is needed to extend or debug the DSL
• Layout constraints and flex layout — OrbTk uses constraint-based and flex-style layouts (visible in layout_constraints.png); core to building responsive UIs without manual positioning

• rust-windowing/winit — Cross-platform window and event handling abstraction that OrbTk could depend on instead of orbclient for non-Redox targets
• iced-rs/iced — The successor toolkit that original maintainers migrated to; offers similar ECS-like patterns but with more active development and broader platform support
• slint-ui/slint — Alternative modern Rust GUI toolkit that two core OrbTk maintainers (@FloVanGH, @rzerres) now contribute to; provides better renderer agnosticism
• redox-os/redox — The Redox OS kernel and ecosystem that OrbTk was created to serve—many Redox applications still depend on OrbTk for UI
• gfx-rs/wgpu — Modern GPU graphics abstraction that could replace tinyskia for high-performance rendering on supported platforms

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for orbtk_core widget base implementation

The orbtk_core directory contains foundational widget logic but lacks visible test coverage. Given that this is a UI toolkit used by multiple Redox applications, adding unit tests for the core widget lifecycle, property binding, and event handling would significantly improve reliability and prevent regressions. This is especially important for a sunsetting project to ensure stability for dependent applications.

• [ ] Examine orbtk_core/src structure (appears to be missing from file list - explore the actual module layout)
• [ ] Create tests/widget_lifecycle_tests.rs covering widget initialization, property updates, and cleanup
• [ ] Create tests/event_handling_tests.rs for event propagation and message passing (referenced in examples/msg_handler.rs)
• [ ] Run tests with cargo test -p orbtk_core and document coverage in README

Migrate GitHub Actions workflow to explicitly test all workspace members

.github/workflows/orbtk.yml exists but the current workflow may not be testing all workspace members (orbtk, orbtk_core, orbtk_widgets, orbtk_orbclient, orbtk_tinyskia, proc_macros, utils). Each member likely has platform-specific requirements. Updating the CI to test each workspace member independently would catch integration issues early and ensure the sunsetting codebase remains stable.

• [ ] Review .github/workflows/orbtk.yml and identify which workspace members are currently tested
• [ ] Add separate test jobs for each member in Cargo.toml [workspace].members
• [ ] Include platform-specific tests (especially for orbtk_orbclient which likely requires specific OS support)
• [ ] Add a check for clippy warnings using clippy.toml configuration

Document the example asset file formats (.ron files) in orbtk/examples/README.md

The examples directory contains .ron configuration files (orbtk/examples/assets/calculator/calculator_dark.ron, popup_de_DE.ron, showcase_de_DE.ron) that are used for theming and localization, but orbtk/examples/README.md likely doesn't explain the .ron format, schema, or how to create custom themes. Adding this documentation would help users understand how to style their OrbTk applications and maintain the project knowledge as it sunsets.

• [ ] Review existing .ron files in orbtk/examples/assets/* to identify common properties and structure
• [ ] Document the RON file format, theming properties, and localization key-value pairs in orbtk/examples/README.md
• [ ] Create a schema example or template showing how to create a custom theme .ron file
• [ ] Link this documentation to the main README.md with a section on 'Styling and Theming'

• Add unit tests for orbtk_widgets/src/ widget components—most widgets lack test coverage despite being core to the API surface.
• Document the ECS pattern and state flow in orbtk_core/src/ with a CONTRIBUTING.md guide showing how to write a custom widget from scratch.
• Complete missing i18n translations: orbtk/examples/assets/ has de_DE locales but lacks en_US and other languages—add RON files for common locales and update showcase.rs to test them.

OrbTk presents a moderate security posture with the primary concern being its sunsetting status and lack of active maintenance. No obvious hardcoded secrets, SQL injection, XSS, or infrastructure misconfigurations were detected in the visible file structure. However, a complete security audit requires examining: (1) all dependency manifests and their versions via 'cargo audit', (2) the actual code in src/ directories for unsafe patterns, (3) the contents of configuration files not provided, and (4) any runtime behaviors that could introduce vulnerabilities. The project's sunset status is the most significant security risk, as future vulnerabilities will likely go unpatched.

• Low · Project is Sunsetting - Maintenance Risk — README.md. According to the README, OrbTk is sunsetting and no longer actively maintained by original developers. Key maintainers have moved to other projects (iced, slint). This means security vulnerabilities and bugs may not be patched in a timely manner. Fix: Consider migrating to actively maintained UI frameworks like iced or slint. If continuing to use OrbTk, conduct regular security audits and maintain a fork with necessary security patches.
• Medium · Incomplete Dependency Analysis — Cargo.toml, orbtk_core/Cargo.toml, orbtk/Cargo.toml. The provided Cargo.toml shows workspace structure but not explicit dependency versions or lock file content. Cannot fully assess if insecure or vulnerable transitive dependencies are present without examining Cargo.lock and individual crate manifests. Fix: Run 'cargo audit' to identify known vulnerabilities in dependencies. Review and pin versions of critical dependencies. Maintain and review Cargo.lock file regularly.
• Low · Default Dev Optimization Level — Cargo.toml. The [profile.dev] section sets opt-level = 1, which provides minimal optimization. While not a direct security issue, lower optimization can impact runtime safety and performance characteristics in debug builds. Fix: Consider using opt-level = 2 or higher for development builds. Ensure release builds use appropriate optimization levels (opt-level = 3).
• Low · Configuration Files Not Examined — .vscode/*, clippy.toml. Several configuration files are present (.vscode/launch.json, .vscode/tasks.json, clippy.toml) but their contents were not provided for security review. These could potentially contain sensitive information or unsafe configurations. Fix: Review configuration files for hardcoded credentials, unsafe compiler flags, or security-sensitive settings. Ensure .vscode/launch.json does not expose debugging ports or contain secrets.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/redox-os/orbtk shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live redox-os/orbtk repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/redox-os/orbtk.

What it runs against: a local clone of redox-os/orbtk — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in redox-os/orbtk | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1331 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of redox-os/orbtk. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/redox-os/orbtk.git
#   cd orbtk
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of redox-os/orbtk and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "redox-os/orbtk(\\.git)?\\b" \\
  && ok "origin remote is redox-os/orbtk" \\
  || miss "origin remote is not redox-os/orbtk (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify develop >/dev/null 2>&1 \\
  && ok "default branch develop exists" \\
  || miss "default branch develop no longer exists"

# 4. Critical files exist
test -f "orbtk/src/lib.rs" \\
  && ok "orbtk/src/lib.rs" \\
  || miss "missing critical file: orbtk/src/lib.rs"
test -f "orbtk/src/application.rs" \\
  && ok "orbtk/src/application.rs" \\
  || miss "missing critical file: orbtk/src/application.rs"
test -f "orbtk_core/src/lib.rs" \\
  && ok "orbtk_core/src/lib.rs" \\
  || miss "missing critical file: orbtk_core/src/lib.rs"
test -f "orbtk_core/src/event/mod.rs" \\
  && ok "orbtk_core/src/event/mod.rs" \\
  || miss "missing critical file: orbtk_core/src/event/mod.rs"
test -f "orbtk_core/src/layout/mod.rs" \\
  && ok "orbtk_core/src/layout/mod.rs" \\
  || miss "missing critical file: orbtk_core/src/layout/mod.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1331 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1301d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/redox-os/orbtk"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.