feat(linux): package the desktop client for Flathub

[plusmobileapps]

Adds the Flatpak packaging for the Linux desktop client, plus the app-side fixes needed for it to actually work inside the sandbox.

What's here

packaging/linux/ — the four files that get committed to the Flathub repository, kept in this repo so they're reviewed and version-bumped alongside the code they package:

• com.plusmobileapps.chefmate.yml — the manifest
• com.plusmobileapps.chefmate.metainfo.xml — AppStream listing, OARS rating, releases
• com.plusmobileapps.chefmate.desktop — desktop entry exported by the sandbox
• chef-mate.sh — launcher shim at /app/bin/chef-mate

Sandbox fixes — each of these is a real breakage under Flatpak, not cosmetics:

Change	Why
DriverFactory.jvm.kt honors XDG_DATA_HOME	The hardcoded ~/.local/share/chef-mate isn't mounted in the sandbox. Same path outside Flatpak.
DesktopUpdater disabled under Flatpak	Read-only install; Flathub owns updates. Same reasoning as the macOS/Windows store builds.
SchemeRegistrar skips self-registration	It would write a handler pointing at a sandbox-internal launcher path the host can't run. The exported .desktop declares x-scheme-handler/chefmate instead.
main.kt pins awtAppClassName	X11 otherwise derives WM_CLASS from the main class name, so the window doesn't match StartupWMClass and appears as a second unnamed dock entry.

platform/Flatpak.kt is the shared FLATPAK_ID / /.flatpak-info probe.

CI — Desktop Release now stages chef-mate-<version>-linux-x86_64.tar.gz (jpackage app image with its bundled jlink runtime, hicolor icons resized from the 584x584 source, LICENSE) and attaches it to the GitHub Release. The .deb leg is unchanged.

Why it's not a source build

Flathub prefers manifests that compile in the build sandbox with no network. That isn't reachable here: every client/* module applies the Android Gradle plugin, so even the JVM target needs the Android SDK just to configure, and the SDK isn't redistributable so it can't be a Flatpak source. On top of that, an offline Gradle build would need every Maven artifact, the Gradle distribution, and the Kotlin compiler pinned as manifest sources.

So the manifest consumes the upstream-built tarball — the same shape Flathub accepts for other large JVM apps (IntelliJ IDEA Community is Apache-2.0 and still ships an upstream tarball). Reviewers may well push on this; the rationale is written up in packaging/linux/README.md.

Runtime choices

• org.gnome.Platform//50, not Freedesktop — JavaFX (the in-app recipe browser's WebView) links against GTK 3, which the Freedesktop runtime doesn't ship.
• Plain --socket=x11, not fallback-x11 — Compose Desktop renders through AWT/Skiko and JavaFX through GTK; neither has a Wayland backend, so both need XWayland even in a Wayland session. The shim pins GDK_BACKEND=x11.
• --filesystem=xdg-pictures/documents/download — the pickers are java.awt.FileDialog, which browses the sandbox filesystem directly and never reaches the document portal.

Reviewer notes

• The flatpak build is untested. flatpak-builder needs Linux and this was authored on macOS. JVM compile passes and ktfmt is clean, but the manifest, the WM_CLASS value, and the app-image directory name the CI step globs for are unverified against a real build.
• Two hard blockers remain before submission, both listed in the packaging README: the screenshots referenced by the metainfo don't exist yet, and the manifest's sha256 is a placeholder until a release publishes the tarball.
• Flathub's generative AI policy applies to the app, the manifest, the PR, and the review replies — worth reading before opening anything against flathub/flathub.
• Nothing in this repo pushes to Flathub. Once submitted, x-checker-data drives version bumps via Flathub's external-data-checker.

🤖 Generated with Claude Code