Wires in the option-(a) sidecar approach: the AppImage carries a
bundled AppImageUpdate AppImage and an embedded update-info string
in the .upd_info ELF section. BackendConnection drives both the
check and the apply via QProcess.
BackendConnection:
- Q_INVOKABLE checkForUpdates()
Bundled mode only. Spawns AppImageUpdate.AppImage with
--check-for-update <APPIMAGE>. Exits 0 → noUpdatesAvailable,
1 → updatesAvailable, anything else → updateCheckFailed.
Dev mode: emits updateCheckFailed("…dev-mode only").
- Q_INVOKABLE applyUpdate()
Bundled mode only. Spawns AppImageUpdate.AppImage with
--remove-old <APPIMAGE>. Replaces the running AppImage in
place; user must restart. Emits updateApplied or
updateApplyFailed.
- Sidecar path resolves to applicationDirPath()/AppImageUpdate.AppImage
by default, overridable via BRIDGE_APPIMAGEUPDATE_BIN.
- APPIMAGE env (set by the AppImage runtime) determines the target
file. Outside an AppImage both methods fail loudly.
build-appimage.sh:
- Auto-downloads AppImageUpdate-x86_64.AppImage into the cached
tools dir and copies it into AppDir/usr/bin/AppImageUpdate.AppImage.
- New --update-info flag, forwarded to appimagetool's -u so the
.upd_info ELF section carries an "zsync|<URL>" string the sidecar
will fetch.
examples/todo Makefile forwards APPIMAGE_UPDATE_INFO env to the
script as --update-info.
release.yml:
- Builds the AppImage with APPIMAGE_UPDATE_INFO set to the canonical
Gitea Releases asset URL for this tag.
- Installs zsync, runs zsyncmake to generate Todo-x86_64.AppImage.zsync.
- Generates a JSON appcast (latest.json) with version / url / sha256 /
size / zsync URL / released_at — useful as an HTTP-fetchable
fallback for clients that prefer a structured manifest.
- SHA256SUMS now covers AppImage + zsync + latest.json.
- Uploads all four assets to the Gitea Release.
AppImage size grows from ~104 MB to ~152 MB with the sidecar bundled.
Embedding verified: objdump shows .upd_info populated with the
expected zsync URL after a local build.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
examples/todo
The framework's POC application: a real Qt/QML todo app whose backend is a Symfony service generated entirely by the make:bridge:* makers. Demonstrates every architectural primitive in PLAN.md §13 Phase 3.
What's here that wasn't in the skeleton
Todoresource (entity + controller + QML snippet) generated viamake:bridge:resource Todo.MarkAllDonecommand generated viamake:bridge:command MarkAllDone, with a body that flipsdone = trueon every todo.TodoWindow.qmlsecond-window scaffold generated viamake:bridge:window Todo, customised to embed a read-only mirror of the sameReactiveListModel.Main.qmlrewritten as a real list UI with add input, per-row toggle/delete, "mark all done", and "open second window".
Everything cross-side (PHP ↔ QML) is maker-generated. There is no handwritten bridge glue in this example.
Run it
make install # composer install
make build # cmake + qt host
make doctor # bridge:doctor — readiness check
make dev # FrankenPHP --watch + Qt host
Add a few todos, toggle them, click "Mark all done", click "Open second window" — both windows stay in sync.
Multi-window test
make devstarts the app.- Add three todos via the input field.
- Click Open second window. A
Todos (mirror)window opens. - In the main window, toggle one of the todos. The mirror flips its row within ~50 ms (Mercure SSE).
- Add a new todo in the main window. It appears in the mirror within ~50 ms.
- Click Mark all done in the main window. Both windows show all rows ticked simultaneously.
Each window has its own ReactiveListModel instance subscribed to the same app://model/todo topic; the framework keeps them coherent without per-window glue.
Crash-and-recover test
make devis running.- Add a todo so the list is non-empty.
- From another terminal:
pkill -f 'examples/todo/symfony.*frankenphp'. - The app's
AppShellshows the Reconnecting banner (visible on the second window; the main window keeps its own status display). - Restart the FrankenPHP child: from the example dir,
cd symfony && frankenphp run --watch --config ../Caddyfile— or just re-runmake dev. - The app flips back to Online and re-fetches the list. No row corruption.
Layout
todo/
Caddyfile # FrankenPHP / Mercure config (port 8765, anonymous SSE)
Makefile # build / dev / doctor / quality
scripts/dev.sh
symfony/
composer.json # path repo points one level deeper at framework/php
config/
src/Entity/Todo.php # generated by make:bridge:resource
src/Controller/TodoController.php # generated, CRUD on /api/todos
src/Controller/MarkAllDoneController.php # generated, body filled in
public/index.php
bin/console
.env
migrations/
qml/
CMakeLists.txt
main.cpp
Main.qml # real todo UI (add / toggle / delete / mark-all / 2nd-window)
TodoList.qml # generated; also reused by the second window
TodoWindow.qml # generated, customised to embed mirror list
What this example proves
- The headline workflow scales: a non-trivial app's PHP/QML wiring is all generated.
ReactiveListModelhandles in-flight optimistic mutations (pendingrole drops opacity on toggled rows until the Mercure echo lands).- Two windows of the same QML app stay coherent under mutations from either side.
- Stopping FrankenPHP mid-session triggers
Reconnecting→OfflineUI; restart restoresOnlineand re-fetches without dupes. Idempotency-Keyround-trips through to Mercure ascorrelationKey— visible indev.logif yougrep correlationKey.
Out of scope here
- A CI-driven version of the multi-window / crash-recover tests lives in Phase 3 sub-commit 4 as a bridge-integration suite.
- No persistence options (export, backup) — same SQLite
var/data.sqliteas the skeleton. Apps move to Postgres by overridingDATABASE_URL.