Skip to content

feat(flathub): ship the Lab on Flathub from its released tar.gz - #897

Merged
kdroidFilter merged 1 commit into
nucleus-3.0from
feat/flathub-lab
Nov 1, 2026
Merged

kdroidFilter merged 1 commit into
nucleus-3.0from
feat/flathub-lab

Conversation

@kdroidFilter

Copy link
Copy Markdown
Collaborator

What

The Lab can ship on Flathub as dev.nucleusframework.Lab without Flathub building from source: the manifest repackages the GraalVM native image the release already produces. This is the path a closed-source Nucleus app takes, and the Lab serves as its demo.

  • release-desktop now builds packageGraalvmTar on both Linux legs and publishes the tar.gz (only the GraalVM output, so the Windows ARM JVM leg does not add one).
  • examples/lab/app/packaging/flathub/: manifest template (GNOME 51 runtime, GTK 3 is required), desktop entry, metainfo, MIME type, 512 px icon, three screenshots, and render-manifest.sh, which renders the content of the future flathub/dev.nucleusframework.Lab repo from a GitHub release (--release <tag>) or from local archives (--local).
  • docs/internals/flathub.md: manifest choices, the local repo loop, linting with Flathub's flags, screenshots, domain verification.

Run-time fixes found by running the Lab as a Flatpak

These affect every Nucleus app repackaged this way.

Symptom Cause Fix
Only the close button on GNOME (Ubuntu) GSettings inside a Flatpak reads the app's keyfile, so button-layout = schema default appmenu:close nucleus_layout_direction_linux.c reads and watches the key through org.freedesktop.portal.Settings (ReadOne/Read, SettingChanged) when sandboxed; GSettings unchanged elsewhere
Window app_id = nucleus-lab GTK sends the executable's name Tao sets the program name to FLATPAK_ID before GTK starts
isFlatpak() / isSandboxed() false The archive's marker says tar ExecutableRuntime.type() checks /.flatpak-info before the marker (the system property still wins)

Verification

  • Lab 1.0.0 → 1.0.1 → 1.0.2 built into a local OSTree repo, installed and updated as real Flatpak updates.
  • WAYLAND_DEBUG: set_app_id("dev.nucleusframework.Lab"). Overview probe shows FLATPAK · sandboxed. The three title bar buttons are back on Ubuntu GNOME (checked by hand).
  • flatpak-builder-lint manifest and repo: clean, on a build made with Flathub's own flathub-build.
  • :core-runtime:test (2 new tests), apiCheck, detekt, ktlintCheck; the C bridge compiles clean with -Wall -Wextra.

Not in this PR

  • The Flathub submission itself (after a dev tag publishes the tar.gz; screenshots are referenced at the tag).
  • The flatpak updates module (UpdateMonitor), the Flathub counterpart of MicrosoftStore.updates.

Flathub repackages the GraalVM native image instead of building from
source, the path a closed-source Nucleus app takes. Running the Lab from
a local Flatpak repository turned up three run-time bugs every such app
would hit:

- ExecutableRuntime reported the archive's marker (TAR): /.flatpak-info
  now wins over it, so the app reports FLATPAK and isSandboxed()
- the Wayland app_id was the executable's name: Tao sets the GTK program
  name to FLATPAK_ID before GTK starts
- GNOME minimize/maximize vanished: GSettings only sees the app's keyfile
  in a sandbox, so button-layout is read and watched through the Settings
  portal there

release-desktop now publishes the Linux tar.gz; the manifest, metainfo,
screenshots and the local repository loop live in
examples/lab/app/packaging/flathub and docs/internals/flathub.md.
@kdroidFilter
kdroidFilter merged commit 4be74c1 into nucleus-3.0 Nov 1, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant