Desktop — Linux, macOS, Windows

Trois chantiers desktop, à des stades différents mais tous les trois avec désormais une vraie app qui tourne (ou, pour Windows/macOS, qui compile réellement en CI sur un vrai runner de la plateforme visée).

WARNING

Linux a été testé par un humain, sur un vrai poste, avec de vraies captures d'écran. macOS et Windows n'ont pas encore été cliqués sur une vraie machine — vérifiés uniquement par CI (compilation réelle sur des runners macos-14/windows-latest, pas juste ubuntu-latest). C'est plus vérifié que ça n'en a l'air, mais ce n'est pas la même chose qu'un clic réel.

Le moteur de rendu partagé, en Rust

Les quatre moteurs de rendu séparés (Android, iOS/macOS, Linux, et ce que Windows aurait dû écrire de zéro) ont été remplacés par un seul moteur écrit une fois, en Rust (tiny-skia pour le dessin, cosmic-text pour le texte), qui rejoue le même protocole JSON que chaque plateforme utilisait déjà séparément. Décision assumée : un moteur partagé, quitte à ce que ce soit un chantier plus lourd que quatre moteurs plus simples.

Ce moteur gère aujourd'hui : formes de base (rects arrondis, cercles, lignes, arcs), gradients et ombres portées, texte/icônes, images inline (data:image/png;base64,...), spinners/skeletons animés, curseurs (slider), panneaux/listes déroulantes imbriqués (clientPanel/hScroll/vScroll) — avec leur interactivité live (changement d'onglet, glissement de scroll, drag du curseur, pas juste leur état "au repos" envoyé par le serveur) —, et les transitions crossfade + hero (l'effet "élément partagé qui vole d'un écran à l'autre") — porté formule par formule depuis l'implémentation Android d'origine.

Où il tourne réellement en production : Linux (par défaut) et Windows (seul chemin possible, ce port n'a jamais eu de moteur natif). Où il existe mais reste à côté du moteur natif existant : macOS a une vraie app séparée qui le consomme ; iOS et Android ont les liaisons complètes mais aucun test sur un vrai appareil n'a jamais pu être fait, donc leur moteur de production reste le rendu natif historique (Core Graphics / android.graphics.Canvas) tant que ça n'a pas changé.

Linux — Rust par défaut, testé sur une vraie machine

GTK4, en Python, avec le moteur Rust comme chemin de rendu par défaut (PHPNITRO_RUST_RENDER=0 repasse sur l'ancien chemin Cairo/Pango, conservé intact).

Pas de PHP embarqué à construire, contrairement au mobile : lance simplement le php système en sous-processus, exactement ce que phpx serve fait déjà pour le dev local.

cd linux
python3 -m phpnitro_desktop /chemin/vers/un/projet-phpnitro   # comme :app, lance php -S soi-même
python3 -m phpnitro_desktop --connect 192.168.1.23:8090        # client pur, façon PhpNitro Go

Vérifié réellement, sur un vrai poste de travail : capture d'écran d'une vraie fenêtre GTK4 tournant sur un vrai bureau Linux, compteur cliqué et incrémenté plusieurs fois, texte rendu en Roboto (la police que le calcul de layout PHP suppose, bundlée explicitement pour que la largeur mesurée corresponde à la largeur dessinée). Plus de 50 tests automatisés, y compris des assertions sur de vrais pixels, un vrai php -S avec un vrai aller-retour HTTP, et un vrai widget GTK4 cliqué.

Ce qui manque : pas de scan QR pour le mode PhpNitro Go (--connect en ligne de commande le remplace) ; images réseau (https://) ou non-PNG, hors de portée pour l'instant côté moteur Rust.

macOS — une vraie app, séparée du moteur Core Graphics existant

Deux chemins de rendu coexistent volontairement, sans risque pour celui qui marchait déjà : le moteur Core Graphics historique (partagé avec iOS, jamais modifié) reste la référence, et une toute nouvelle app exécutable (swift run PhpNitroMacApp <projet>) consomme le moteur Rust partagé de bout en bout — son propre client HTTP, son propre rendu, son propre routage de clics.

Comme sur Linux, pas de PHP embarqué à construire : macOS n'a pas la restriction d'Apple qui empêche de lancer un vrai sous-processus, donc le php système suffit.

Jamais lancée sur un vrai Mac — vérifiée uniquement par CI, mais une CI qui compile réellement les deux chemins (le moteur Core Graphics existant et la nouvelle app Rust) sur un vrai runner macos-14.

Comme sur Linux, deux modes de lancement :

swift run PhpNitroMacApp /chemin/vers/un/projet-phpnitro   # lance php -S soi-même
swift run PhpNitroMacApp --connect 192.168.1.23:8090        # client pur, façon PhpNitro Go

Ce qui manque : aucun clic réel, pas de saisie clavier dans la nouvelle app Rust, pas de scan QR (--connect en ligne de commande le remplace).

Windows — une vraie app WinForms, moteur Rust uniquement

Contrairement aux trois autres plateformes, Windows n'a jamais eu de moteur de rendu natif (ni GDI+, ni Direct2D) — le moteur Rust partagé est donc son seul et unique chemin de rendu, pas un remplacement d'un existant. Une vraie app WinForms lance le php système en sous-processus (comme sur Linux/macOS), fetch un écran, le peint en convertissant le buffer de pixels du moteur Rust vers le format attendu par GDI+, et route les clics vers la bonne action.

Vérifiée réellement en CI, pour la première fois sur un vrai runner windows-latest — jusqu'ici, tout ce qui touchait Windows dans ce projet ne tournait que sur ubuntu-latest (la seule chose vérifiable sans machine Windows). C'est la première fois que ce dossier peut dire "compilé sur un vrai Windows", même si personne ne l'a encore cliqué.

Comme sur Linux/macOS, deux modes de lancement :

PhpNitroDesktop.App.exe C:\chemin\vers\un\projet-phpnitro   # lance php -S soi-même
PhpNitroDesktop.App.exe --connect 192.168.1.23:8090          # client pur, façon PhpNitro Go

Ce qui manque : aucun clic réel sur une vraie machine Windows, pas de saisie clavier, taille de fenêtre fixe (pas de redimensionnement live).

Pourquoi ces choix techniques

• Linux avait Python/GTK4 déjà installés, mais pas les en-têtes de développement pour compiler du C contre GTK4 directement — Python n'était donc pas une préférence, c'était la seule option qui compilait.
• macOS a pu réutiliser tel quel le travail iOS déjà fait et vérifié pour son moteur Core Graphics, ce qui en a fait le chantier le "moins risqué" des trois au départ malgré l'absence totale de Mac.
• Windows n'avait initialement aucun outil .NET/C# disponible du tout — la couche protocole a été écrite en premier, sans jamais pouvoir la relire même syntaxiquement, avant qu'un moteur de rendu partagé en Rust ne rende la question "GDI+ ou Direct2D ?" caduque : un seul moteur, écrit une fois, à brancher partout plutôt qu'à réécrire une quatrième fois.

Voir l'architecture générale →