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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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