Research: is a Flatpak of PolterType viable at all?

[vstrelnikof]

People will ask for a Flathub listing eventually. Before anyone spends a weekend on it, the honest question is whether PolterType can work inside the Flatpak sandbox without punching holes so wide the listing gets flagged:

• The listener reads /dev/input (evdev) and the emitter writes through uinput — both blocked by default. --device=input covers read; uinput generally means --device=all plus the host udev rule anyway.
• Layout switching shells out to / talks to compositor- and DE-specific backends (hyprctl, GSettings, IBus, Fcitx5, KDE) — several of those need --talk-name/filesystem holes from a sandbox.
• Autostart writes an XDG autostart entry — portals have an API for that one (org.freedesktop.portal.Background), which would actually be cleaner than what we do today.
• The self-updater must stand down inside Flatpak (it already refuses to touch installs that aren't our AppImage/MSI/DMG — verify $FLATPAK_ID lands in that path).

Deliverable: a short write-up in this issue — required permissions list, whether Flathub review policy tolerates it for this app class (precedents: input remappers on Flathub ship with --device=all), and a go/no-go recommendation. "No, AppImage + native packages is the honest Linux story" is a perfectly good outcome; the point is to decide once, with evidence, and link the decision from the README FAQ.

[vstrelnikof]

Go/no-go: no. AppImage plus native packages is the honest Linux story.
Written up in docs/DECISIONS.md (2026-07-31) and stated plainly in the README
so nobody has to ask twice. PR #17.

The blocker is uinput, and it is hard. device=input was introduced for
game controllers and deliberately excludes /dev/uinput — the original patch
carried /dev/uinput and /dev/hidraw* and that part was removed before it
landed (Flathub discourse).
So the only permission that gets us a virtual keyboard is --device=all: the
whole device tree, webcam and disks included. Flathub requires that "static
permissions must be kept to an absolute minimum" and that a portal, where one
exists, is mandatory rather than optional
(requirements) —
and there is no portal for creating a virtual input device. Without uinput
PolterType cannot type, which is the entire product.

Precedent agrees. input-remapper's Flathub request was closed as
technically infeasible on exactly this reasoning
(thread).
We are in that class of app.

Even granting everything, DE integration stays broken. Layout switching
shells out to hyprctl, gsettings, qdbus, ibus and fcitx5-remote —
host binaries that do not exist inside the runtime. flatpak-spawn --host
would work and is precisely "bypassing security mechanisms" in Flathub's
words. A Flatpak needing --device=all and host command execution is not a
sandboxed app; it is an AppImage with extra steps and a misleading padlock.

What a Flatpak would genuinely improve is autostart:
org.freedesktop.portal.Background is cleaner than the XDG .desktop entry we
write today. One clean win against a load-bearing blocker is not a trade.

Verified, not assumed: the updater already stands down inside Flatpak, and
by the right mechanism — apply/linux.rs requires $APPIMAGE to be set, an
allowlist rather than a denylist of $FLATPAK_ID and friends, so any install
that is not our own AppImage refuses and points at the Releases page. Nothing
to change there whatever we decided. (It still downloads before discovering
it cannot install — a small waste for every packaged user, worth fixing on its
own merits and independent of this decision.)

Revisit if a portal for virtual input devices appears — something
InputCapture-shaped that covers emitting rather than only capturing — or if
device=input regains /dev/uinput. Both would have to land and be widely
deployed before a listing would be worth the maintenance.