You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A landscape survey of similar projects is now committed at docs/research/landscape.md. This issue is for the review pass on that survey and for follow-up study of the five closest peers it identified.
What the survey found
deckd sits in a niche no surveyed project fills in full. The combination pure-browser client + host-OS app-focus detection + arbitrary input injection (keys/scroll/trackpad) on the host OS + per-website heuristic is unique. Every peer misses at least one of those four.
The five closest peers, one per axis, are:
Bitfocus Companion (MIT) — closest in what it does at the surface (web button grid + page swap + huge integration surface), but it's a pro-AV shotbox, the web "Buttons" view is a side feature, and it doesn't inject into the host OS.
StreamController (GPL-3.0) — closest Linux-native peer for per-app auto-switching, but hardware-bound to Elgato Stream Deck devices. Worth studying the page-switch UX even if we never touch the hardware.
Kando (MIT) — closest in philosophy (free software, plain formats, declarative per-app rules, fully open). Pie menu, not a grid — different UX, same design idea.
portway (MIT) — closest in transport shape (browser client + uinput on Linux + small Rust daemon + no cloud). No deck layer.
Remote Touchpad (GPL-3.0) — the canonical older browser-based remote-input project (already in the README's comparison table). Smallest, simplest, longest-running, GPL.
A possible 6th, more aspirational: Hammerspoon (Mac, MIT) is the engineering peer — a tiny Lua-scriptable daemon that programmers extend to do exactly this kind of thing. Worth studying for API ergonomics, even though its visual surface is "anything hs.canvas can draw," not a polished button grid.
What to review / next steps
Read the survey end-to-end (it has a confidence footer — flag anything where my source-verification was weak, e.g. Elgato's literal "Smart Profiles" name, Touch Portal Pro gating, Deckboard's current state).
For each of the five peers above, write a short note (1–2 paragraphs in a comment below) on: what deckd should learn from them, and what deckd should explicitly not copy. This is the "study" half.
Decide which peer is the highest priority to study first. A reasonable default order: Companion (surface UX), portway (transport shape), StreamController (Linux auto-switch UX), Kando (declarative-rules design), Remote Touchpad (smallest reference). The agent or person picking this up should pick one and go deep, then come back for the next.
Open questions / follow-ups the survey flagged
The per-website / per-URL matching is a genuine differentiator and the only open-source project that documents the same browser-title heuristic is Espanso's filter_title (text expander, not a control surface). The promised browser-extension URL matching (#90) would make this category-unique. Question for review: is the extension work unblocked, or is the heuristic the right thing to lean on for the next release?
The "no install on the phone" promise is what separates deckd from Touch Portal, Tacto, and Macro Deck. Question for review: is the README loud enough about this? The comparison table already has it as a row but the marketing copy could carry it harder.
README comparison table is narrower than the survey. It lists Stream Deck / KDE Connect / Apple Touch Bar / Remote Touchpad / OpenDeck / Boatswain. Worth considering whether to expand it to include the survey's closer peers (Companion, Kando, StreamController, Touch Portal, portway, Macro Deck). Easy follow-up; the survey has the data already.
KVM fork line is collapsing (Input Leap archived 2026-07-26, Barrier silent since 2022). Not directly deckd's space but a market signal worth keeping an eye on. The phone-as-input projects (Remote Touchpad, portway, KDE Connect's plugin) are picking up energy.
This is a review and study ticket, not a build ticket. No code changes implied. Concrete peer-study notes should land as comments on this issue, not as separate PRs.
A landscape survey of similar projects is now committed at docs/research/landscape.md. This issue is for the review pass on that survey and for follow-up study of the five closest peers it identified.
What the survey found
deckd sits in a niche no surveyed project fills in full. The combination pure-browser client + host-OS app-focus detection + arbitrary input injection (keys/scroll/trackpad) on the host OS + per-website heuristic is unique. Every peer misses at least one of those four.
The five closest peers, one per axis, are:
A possible 6th, more aspirational: Hammerspoon (Mac, MIT) is the engineering peer — a tiny Lua-scriptable daemon that programmers extend to do exactly this kind of thing. Worth studying for API ergonomics, even though its visual surface is "anything
hs.canvascan draw," not a polished button grid.What to review / next steps
Open questions / follow-ups the survey flagged
filter_title(text expander, not a control surface). The promised browser-extension URL matching (#90) would make this category-unique. Question for review: is the extension work unblocked, or is the heuristic the right thing to lean on for the next release?Files
Out of scope (deliberately)
This is a review and study ticket, not a build ticket. No code changes implied. Concrete peer-study notes should land as comments on this issue, not as separate PRs.