27 lines
2.2 KiB
Markdown
27 lines
2.2 KiB
Markdown
# 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](https://github.com/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.
|