Panama/docs/UPSTREAM-INSPIRATION.md

Upstream inspiration

Panama is its own desktop experience, but it should learn from strong open-source work without obscuring where an idea came from. This ledger records upstream projects that materially influence its architecture or interaction design.

Omarchy

• Project: basecamp/omarchy
• Reviewed revision: f32ebbdb730c4e8fe11e4046cef4267e466264ea
• License: MIT, copyright David Heinemeier Hansson
• Local reference at review time: /home/gib/Documents/Code/Projects/omarchy

Adopted ideas, rebuilt for Panama

• shell/plugins/osd/Osd.qml and OsdModel.js: inspired the separation between a pure presentation model and a single, click-through per-monitor OSD surface. Panama rebuilt the behavior around freedesktop symbolic icons, Tokyo Night Moon tokens, its Prism glass material, Hyprland's focused monitor, and the existing wpctl/brightnessctl/playerctl keybindings.
• test/shell.d/osd-test.sh and Omarchy's broader shell contract suite: reinforced Panama's use of fast model and integration contracts alongside live compositor verification.
• Omarchy's small shared visual primitives: reinforced the decision to maintain prism-gallery.qml, which renders Panama's production widgets and Theme tokens instead of duplicating mock-only controls.
• shell/plugins/menu/Menu.qml: inspired a searchable desktop-action inventory. Panama keeps Vicinae as its one launcher and exposes native script commands backed by a single panama-action dispatcher, rather than adding Omarchy's separate shell menu or plugin host.

No Omarchy user-facing layout or styling was transplanted. Panama keeps its GNOME-derived information architecture, Prism material, Tokyo Night Moon palette, app model, and established interaction choices.

Candidates still under evaluation

• A plugin boundary for optional bar widgets and services once Panama has enough third-party modules to justify one.
• A small first-run health check for missing desktop dependencies and broken service integrations.

These are research directions, not commitments. They should only land when they improve the daily-driver experience without adding visible complexity or parallel configuration systems.