requirements.txt installait mlx-whisper sans condition : l'installation aurait
echoue sur Windows, ou ce paquet n'existe pas. Et pyobjc n'y figurait PAS DU TOUT
alors que l'overlay macOS en depend — une installation neuve sur un autre Mac
aurait produit une Zonza qui ne demarre pas. Les marqueurs retiennent 13 paquets
sur Apple Silicon, 12 sur Mac Intel, 8 sur Windows.
install.sh construit l'app et lance le diagnostic. install.ps1 pose le lancement
au demarrage via pythonw (sans quoi une console resterait ouverte) et lance le
diagnostic. Ce dernier porte un avertissement : il n'a jamais tourne sur Windows.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sur macOS Tahoe (26.5), le NSStatusItem n'est jamais placé (fenêtre h=0) si :
1. l'exécutable du processus n'appartient pas au bundle lancé (le python
framework se ré-exécute → identité dépareillée) → stub C qui dlopen
libpython et exécute app.py DANS le processus du bundle ;
2. l'item est créé par rumps (cause interne non isolée, l'API native
fonctionne) → app.py réécrit en pyobjc pur (NSStatusItem + NSMenu).
Le stub transmet argv à python quand il y en a (workers multiprocessing
de MLX) — sinon bombe à fork (9 instances observées). PYTHONUNBUFFERED
pour que les print atteignent ~/Library/Logs/Zonza.log. Auto-diagnostic
du placement de l'icône au démarrage. rumps retiré des dépendances.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Reconstruction propre de l'ancien projet Dictée. Bundle id neuf
(cloud.mrtechlab.zonza), chemin de build unique vers /Applications
(plus jamais de builds /tmp enregistrés dans LaunchServices).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
