Skip to content

Review landscape survey and study closest peers (Companion, StreamController, Kando, portway, Remote Touchpad) #146

Description

@jonocodes

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:

  1. 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.
  2. 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.
  3. 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.
  4. portway (MIT) — closest in transport shape (browser client + uinput on Linux + small Rust daemon + no cloud). No deck layer.
  5. 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.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-triageMaintainer needs to evaluate this issue

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions