Files
php-qml/examples/todo
magdev fddb70f877 Phase 4a sub-commit 4: AppImageUpdate sidecar + appcast + checkForUpdates()
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>
2026-05-02 19:58:02 +02:00
..

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

  • Todo resource (entity + controller + QML snippet) generated via make:bridge:resource Todo.
  • MarkAllDone command generated via make:bridge:command MarkAllDone, with a body that flips done = true on every todo.
  • TodoWindow.qml second-window scaffold generated via make:bridge:window Todo, customised to embed a read-only mirror of the same ReactiveListModel.
  • Main.qml rewritten 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

  1. make dev starts the app.
  2. Add three todos via the input field.
  3. Click Open second window. A Todos (mirror) window opens.
  4. In the main window, toggle one of the todos. The mirror flips its row within ~50 ms (Mercure SSE).
  5. Add a new todo in the main window. It appears in the mirror within ~50 ms.
  6. 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

  1. make dev is running.
  2. Add a todo so the list is non-empty.
  3. From another terminal: pkill -f 'examples/todo/symfony.*frankenphp'.
  4. The app's AppShell shows the Reconnecting banner (visible on the second window; the main window keeps its own status display).
  5. Restart the FrankenPHP child: from the example dir, cd symfony && frankenphp run --watch --config ../Caddyfile — or just re-run make dev.
  6. 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.
  • ReactiveListModel handles in-flight optimistic mutations (pending role 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 ReconnectingOffline UI; restart restores Online and re-fetches without dupes.
  • Idempotency-Key round-trips through to Mercure as correlationKey — visible in dev.log if you grep 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.sqlite as the skeleton. Apps move to Postgres by overriding DATABASE_URL.