magdev
d671b26cac
Symfony app under framework/skeleton/symfony/: minimal bin/console, public/index.php, MicroKernel-based src/Kernel.php, services.yaml, framework/security/mercure config, and a demo App\Controller\PingController that GETs /api/ping (returning JSON pong) and republishes the same payload to the Mercure topic app://ping. composer.json uses a path repository to symlink the bundle from ../../php so local edits are picked up live. QML app under framework/skeleton/qml/: top-level CMake that add_subdirectory's framework/qml, a main.cpp that creates the Qt process, runs SingleInstance.acquireOrForward before any QML loads, exposes SingleInstance via context property, and loadFromModule's Skeleton.Main. Main.qml uses BackendConnection / RestClient / MercureClient from PhpQml.Bridge and renders status dots, a Ping button, and an event log. Caddyfile binds 127.0.0.1:8765, enables in-memory Mercure with a 256-bit dev JWT (matches symfony/.env, lcobucci/jwt requires this). Makefile wraps build / dev / doctor / clean; scripts/dev.sh starts FrankenPHP --watch and the Qt host together with explicit PID-based teardown (process-group `kill 0` proved unreliable when frankenphp's watch fork reparented). Bug fixes uncovered in this sub-commit: - SingleInstance.acquireOrForward: probe-first, then removeServer + retry-listen. The original loop-with-removeServer-after-failed-bind silently exited on stale sockets from prior runs. - Main.qml: MercureClient does NOT inherit BackendConnection.token — Mercure subscribes anonymously in dev (Caddyfile), and forwarding the bridge bearer made it 401-loop. - /api/ping was 500ing because the dev MERCURE_JWT_SECRET was 144 bits; bumped to 64-char (>=256 bit) to satisfy lcobucci/jwt. - Linked the framework lib (php_qml_bridge) explicitly in addition to the QML plugin so SingleInstance.h resolves. - Auto-generated config/reference.php gitignored. Smoke verified offscreen: /healthz 200, /api/ping 200, 1 publish, 1 subscriber, zero 401s, clean shutdown with no zombies. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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:
- Clone the repository and check out the
devbranch. - Install Qt 6 and PHP 8.x; the FrankenPHP runtime is fetched at build time.
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).