magdev 03061f2f75 Phase 4a sub-commit 3: Linux release CI on v* tags
.gitea/workflows/release.yml builds the example's AppImage on every
v* tag push and uploads it to a Gitea Release together with a signed
SHA256SUMS:

  - Same PHP / Qt / FrankenPHP setup as the quality job (cached).
  - Reuses the AppImage recipe via `make appimage` (FRANKENPHP env
    points at the runner's installed binary; APPIMAGE_EXTRACT_AND_RUN=1
    to avoid FUSE inside CI).
  - sha256sum → SHA256SUMS.
  - When a GPG_KEY secret is present, imports it and emits
    SHA256SUMS.asc (--detach-sign --armor). Skipped silently if
    secrets aren't configured — CI red-lines for real failures, not
    for missing operational secrets.
  - Creates the Release via the Gitea API
    (POST /repos/{repo}/releases) and uploads
    AppImage + SHA256SUMS + SHA256SUMS.asc.

Workflow exists from this commit onward even before a Gitea runner is
provisioned; it'll just fail at the runner-needed steps if no runner
picks it up.

Required Gitea secrets (configurable when ready):
  - GITEA_TOKEN     — repo-scoped token, write:repository
  - GPG_KEY         — ASCII-armoured private key (optional)
  - GPG_PASSPHRASE  — the key's passphrase (optional)

Sub-commit 4 will append a zsync + appcast (latest.json) step here for
auto-update.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 19:50:42 +02:00
2026-05-01 23:58:26 +02:00

php-qml

A framework for building native desktop applications with a Symfony / FrankenPHP backend and a Qt/QML frontend, packaged as a single distributable per OS.

Status

Planning stage. The architectural design lives in PLAN.md. No implementation exists yet — first code lands in Phase 0 (a throwaway transport spike). See the roadmap.

What it is

php-qml lets a PHP developer write a desktop application using ordinary Symfony on the backend and ordinary QML on the frontend. The two halves run as a process pair inside one bundled binary:

  • A Qt/QML host process owns the window, input, and rendering.
  • A bundled FrankenPHP child runs a Symfony application in worker mode.
  • They communicate over a local socket — HTTP for commands and queries, Mercure SSE for state push.

The framework provides the lifecycle, transport, reactive models, and scaffolding so application code stays idiomatic on both sides.

What it is not

Not a PHP↔Qt language binding. It does not embed PHP into a Qt event loop and it does not generate Qt classes from PHP. The two languages run in separate processes; the bridge is a wire protocol, not an FFI layer.

If you've watched php-gtk and php-qt go quiet, that is the failure mode this project deliberately avoids — the framework owns the boring parts (lifecycle, transport, conventions) so it doesn't depend on a single maintainer keeping a language binding alive.

Tech stack

  • Backend: PHP 8.x, Symfony, Doctrine ORM, FrankenPHP (worker mode), Mercure
  • Frontend: Qt 6 LTS, QML, C++ plugin where required
  • Build: CMake, Composer
  • CI: Gitea Actions, Gitea Releases
  • Targets: Linux (AppImage), macOS (.app + .dmg), Windows (NSIS / MSIX)

Getting started

Nothing to run yet. Once Phase 0 lands:

  1. Clone the repository and check out the dev branch.
  2. Install Qt 6 and PHP 8.x; the FrankenPHP runtime is fetched at build time.
  3. task dev — starts FrankenPHP in watch mode and launches the Qt host pointed at it.

Detailed setup will be documented alongside the framework skeleton in Phase 1.

Project structure

See PLAN.md §9 for the intended layout. The repo currently contains only PLAN.md and this README.

Roadmap

Six phases, each ending with something runnable. Detail in PLAN.md §13.

  • Phase 0 — throwaway spike, prove transport on Linux.
  • Phase 1 — framework skeleton, dev mode, single-instance lock, CI quality gate.
  • Phase 2 — reactive models, update semantics, headline maker (make:bridge:resource).
  • Phase 3 — POC todo application generated via the makers; testing infrastructure.
  • Phase 4 — bundled mode, per-OS packaging, release CI, auto-update.
  • Phase 5 — DX polish.

Contributing

Active development happens on the dev branch; main only carries release commits. Pull requests target dev.

A CONTRIBUTING.md will be added with the framework skeleton in Phase 1.

Versioning

Semantic Versioning — MAJOR.MINOR.BUGFIX. MAJOR for breaking changes, MINOR for backwards-compatible features, BUGFIX for backwards-compatible fixes.

License

To be decided before the first release. The framework's own code will be permissively licensed; note that Qt is shipped under LGPL and that carries obligations for distributors — see PLAN.md §12 (Qt LGPL relinkability).

Description
Bridge to run Symfony applications with native QML interfaces
Readme 503 KiB
v0.1.0 Latest
2026-05-03 10:21:14 +00:00
Languages
PHP 44.4%
C++ 34.4%
Shell 10.3%
QML 8.1%
CMake 1.4%
Other 1.4%