fletchtime 0.2.0__tar.gz → 0.2.2__tar.gz

{fletchtime-0.2.0 → fletchtime-0.2.2}/.gitignore

@@ -27,6 +27,10 @@ docs/_build/
 # vrai secret et ne doit jamais être versionné.
 config/auth.toml
 
+# Préférences de la fenêtre graphique (thème...) -- propres à la machine/
+# personne qui lance la fenêtre, pas un réglage de club à partager.
+config/gui.toml
+
 # Instantané du match en cours (récupération après crash) -- propre à une
 # session de match en cours, pas un réglage du club à partager/versionner.
 config/match_state.json

{fletchtime-0.2.0/src/fletchtime.egg-info → fletchtime-0.2.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: fletchtime
-Version: 0.2.0
+Version: 0.2.2
 Summary: Chronométrage de compétitions d'archerie FFTL (Indoor, Flint) -- serveur + interfaces web incluses
 License: GPL-3.0-or-later
 Requires-Python: >=3.11
@@ -21,6 +21,11 @@ Dynamic: license-file
 
 <img src="https://mrfanghodev.github.io/fletchtime/_static/logo.svg" width="80" height="80" alt="FletchTime logo">
 
+[![Python](https://img.shields.io/badge/python-version-from-pep-621-toml?tomlFilePath=https%3A%2F%2Fraw.githubusercontent.com%2FMrFanghoDev%2Ffletchtime%2Fmaster%2Fpyproject.toml)](pyproject.toml)
+[![Licence](https://img.shields.io/github/license/MrFanghoDev/fletchtime)](LICENSE)
+[![Tests](https://github.com/MrFanghoDev/fletchtime/actions/workflows/test.yml/badge.svg?branch=master)](https://github.com/MrFanghoDev/fletchtime/actions/workflows/test.yml)
+[![PyPI](https://img.shields.io/pypi/v/fletchtime)](https://pypi.org/project/fletchtime/)
+
 # FletchTime
 
 Logiciel open source de gestion du temps pour compétitions d'archerie FFTL
@@ -122,6 +127,29 @@ from fletchtime.engine import IndoorMode, IndoorConfig, MatchEngine
 engine = MatchEngine(IndoorMode(IndoorConfig()))
 ```
 
+## Plusieurs salles de compétition sur un même PC
+
+Chaque installation de FletchTime (dossier `pip install`, ou dossier de
+l'exécutable autoporteur) fait tourner **une seule salle** -- son propre
+match, sa propre urgence, sa propre config. Pour plusieurs salles en
+parallèle sur le même PC :
+
+1. **Copie le dossier FletchTime une fois par salle** (ex. `salle-A/`,
+   `salle-B/`) -- ça isole automatiquement `config/` (temps de tir,
+   urgence...), les journaux, et l'instantané de récupération après
+   plantage : chaque copie a sa propre urgence, indépendante des autres.
+2. Dans la fenêtre de chaque copie, section **Ports (HTTP/WS)** : donne
+   des ports différents à chaque salle (ex. salle A garde `8000`/`8765`
+   par défaut, salle B passe à `8001`/`8766`) -- **Appliquer** redémarre
+   le serveur automatiquement si besoin.
+3. Lance chaque copie séparément. Les écrans de chaque salle se
+   connectent à l'adresse (IP + port) affichée dans la fenêtre de leur
+   salle respective.
+
+**Windows** : le pare-feu autorise généralement par chemin d'exécutable --
+avec des copies de dossier séparées, prévoir de valider l'alerte une fois
+par copie au premier lancement.
+
 ## Contribuer
 
 Envie de proposer un correctif, une idée, ou juste signaler un bug ? Voir

{fletchtime-0.2.0 → fletchtime-0.2.2}/README.md

@@ -1,5 +1,10 @@
 <img src="https://mrfanghodev.github.io/fletchtime/_static/logo.svg" width="80" height="80" alt="FletchTime logo">
 
+[![Python](https://img.shields.io/badge/python-version-from-pep-621-toml?tomlFilePath=https%3A%2F%2Fraw.githubusercontent.com%2FMrFanghoDev%2Ffletchtime%2Fmaster%2Fpyproject.toml)](pyproject.toml)
+[![Licence](https://img.shields.io/github/license/MrFanghoDev/fletchtime)](LICENSE)
+[![Tests](https://github.com/MrFanghoDev/fletchtime/actions/workflows/test.yml/badge.svg?branch=master)](https://github.com/MrFanghoDev/fletchtime/actions/workflows/test.yml)
+[![PyPI](https://img.shields.io/pypi/v/fletchtime)](https://pypi.org/project/fletchtime/)
+
 # FletchTime
 
 Logiciel open source de gestion du temps pour compétitions d'archerie FFTL
@@ -101,6 +106,29 @@ from fletchtime.engine import IndoorMode, IndoorConfig, MatchEngine
 engine = MatchEngine(IndoorMode(IndoorConfig()))
 ```
 
+## Plusieurs salles de compétition sur un même PC
+
+Chaque installation de FletchTime (dossier `pip install`, ou dossier de
+l'exécutable autoporteur) fait tourner **une seule salle** -- son propre
+match, sa propre urgence, sa propre config. Pour plusieurs salles en
+parallèle sur le même PC :
+
+1. **Copie le dossier FletchTime une fois par salle** (ex. `salle-A/`,
+   `salle-B/`) -- ça isole automatiquement `config/` (temps de tir,
+   urgence...), les journaux, et l'instantané de récupération après
+   plantage : chaque copie a sa propre urgence, indépendante des autres.
+2. Dans la fenêtre de chaque copie, section **Ports (HTTP/WS)** : donne
+   des ports différents à chaque salle (ex. salle A garde `8000`/`8765`
+   par défaut, salle B passe à `8001`/`8766`) -- **Appliquer** redémarre
+   le serveur automatiquement si besoin.
+3. Lance chaque copie séparément. Les écrans de chaque salle se
+   connectent à l'adresse (IP + port) affichée dans la fenêtre de leur
+   salle respective.
+
+**Windows** : le pare-feu autorise généralement par chemin d'exécutable --
+avec des copies de dossier séparées, prévoir de valider l'alerte une fois
+par copie au premier lancement.
+
 ## Contribuer
 
 Envie de proposer un correctif, une idée, ou juste signaler un bug ? Voir

{fletchtime-0.2.0 → fletchtime-0.2.2}/docs/architecture.md

@@ -343,6 +343,41 @@ confirmer le rendu et l'ergonomie tactile -- voir aussi le piège
 PyInstaller/`customtkinter` documenté dans {doc}`dev-guide/index`.
 ```
 
+## Journal applicatif persistant
+
+En plus du journal affiché dans la fenêtre graphique (en mémoire,
+perdu à la fermeture -- voir `fletchtime.gui._QueueWriter`),
+`fletchtime.logging_setup.configure_logging` écrit un fichier de journal
+persistant (`<données du club>/logs/fletchtime.log`, avec rotation --
+1 Mo par fichier, 5 fichiers conservés) : utile pour comprendre après
+coup ce qui s'est passé pendant un concours, sans dépendre de la mémoire
+volatile de la fenêtre.
+
+`MatchServer` y journalise :
+- chaque commande reçue (`next`, `stop`, `start_indoor`...), avec la lane
+  d'origine si connue ;
+- chaque connexion/déconnexion, avec le nombre de clients restants ;
+- les pertes de connexion réseau détectées (WiFi, mise en veille...),
+  distinguées d'une fermeture normale ;
+- les messages malformés reçus (JSON invalide) ;
+- les transitions d'état significatives (`prep_start`, `shoot_start`,
+  `warning_orange`, `end_of_volee`, `pause_start`/`pause_end`,
+  `emergency_start`/`emergency_end`, `end_of_match`), avec le contexte
+  (unité, volée, tour, phase) -- qu'elles soient déclenchées naturellement
+  par le décompte ou manuellement (`next`, `goto`...), puisque les deux
+  passent par le même mécanisme de collecte d'événements. `countdown_tick`
+  est volontairement exclu (se déclenche une fois par seconde dans les
+  dernières secondes de chaque volée -- noierait le journal sans valeur
+  diagnostique ajoutée).
+
+```{important}
+Le mot de passe (action `authenticate`) n'est **jamais** journalisé -- le
+code ne journalise jamais `data` tel quel, seulement le nom de l'action
+et la lane, précisément pour éviter qu'un secret ne traîne en clair dans
+un fichier qui persiste sur disque. Vérifié par un test dédié
+(`test_password_never_appears_in_logs`).
+```
+
 ## Récupération après un plantage ou redémarrage du serveur
 
 Avant ce mécanisme, un plantage ou un redémarrage du serveur en plein
@@ -398,15 +433,29 @@ comparable à travers un redémarrage du processus.
 `wallclock_deadline` vaut `None` pendant une pause/urgence (le décompte
 est gelé, aucune échéance à calculer) : `time_left` reste alors la
 valeur figée telle quelle, sans recalcul.
+```
+
+```{important}
+**Si l'échéance est déjà dépassée à la restauration** (le temps
+réellement écoulé pendant l'indisponibilité dépasse ce qui restait sur
+l'étape en cours), le match est marqué **terminé** plutôt que de figer
+`time_left` à 0. Sans ça, le tick normal suivant (`MatchEngine.tick()`,
+voir plus haut) aurait déclenché son rattrapage automatique -- pensé
+pour un simple ralentissement passager du serveur, pas une coupure de
+plusieurs minutes -- et avancé à l'étape suivante avec une durée
+fraîche : le chrono semblait alors "redémarrer" du point de vue des
+archers, alors qu'en réalité bien plus de temps s'était écoulé que ce
+que l'étape en cours pouvait raisonnablement absorber. Une coupure trop
+longue pour être absorbée dans l'étape en cours demande donc une
+intervention explicite du responsable du chronométrage (`restart`/
+`goto`) plutôt qu'une reprise automatique qui devinerait une position
+dans une coupure d'une durée arbitraire.
+```
 
 La sauvegarde à chaque tick (plutôt que périodiquement, ex. toutes les
 5s) garde malgré tout sa valeur avec ce mécanisme : elle limite la
-fenêtre pendant laquelle un **changement d'étape complet** (fin de
-volée, passage à l'orange...) pourrait ne pas être capturé avant un
-plantage -- l'échéance recalculée donne un temps exact pour l'étape
-*enregistrée*, mais ne devine jamais qu'une étape différente aurait dû
-être active entre-temps.
-```
+fenêtre pendant laquelle un changement d'étape aurait pu se produire
+juste avant un plantage sans jamais être capturé dans l'instantané.
 
 ## Fonctionnement dégradé en cas de coupure réseau
 

{fletchtime-0.2.0 → fletchtime-0.2.2}/docs/index.md

@@ -1,3 +1,14 @@
+```{image} _static/logo.svg
+:alt: FletchTime
+:width: 140px
+:align: center
+```
+
+[![Python](https://img.shields.io/badge/python-version-from-pep-621-toml?tomlFilePath=https%3A%2F%2Fraw.githubusercontent.com%2FMrFanghoDev%2Ffletchtime%2Fmaster%2Fpyproject.toml)](https://github.com/MrFanghoDev/fletchtime/blob/master/pyproject.toml)
+[![Licence](https://img.shields.io/github/license/MrFanghoDev/fletchtime)](https://github.com/MrFanghoDev/fletchtime/blob/master/LICENSE)
+[![Tests](https://github.com/MrFanghoDev/fletchtime/actions/workflows/test.yml/badge.svg?branch=master)](https://github.com/MrFanghoDev/fletchtime/actions/workflows/test.yml)
+[![PyPI](https://img.shields.io/pypi/v/fletchtime)](https://pypi.org/project/fletchtime/)
+
 # FletchTime
 
 Logiciel de gestion du temps pour compétitions d'archerie FFTL (Indoor et Flint),

{fletchtime-0.2.0 → fletchtime-0.2.2}/docs/roadmap.md

@@ -73,27 +73,50 @@ dépendent d'extensions compilées (Rust/C) peu fiables sur Pydroid 3, voir
 
 ## Backlog — à discuter / non encore programmé dans une étape précise
 
-- **Fenêtre graphique -- améliorations restant à faire** :
-  - Paramétrage du serveur (ports, etc.) et de l'adresse IP exposée sur le
-    réseau local, directement depuis la fenêtre plutôt que fichiers de
-    config seuls.
-  - Affichage des adresses exposées (accueil/contrôle/affichage) dans la
-    fenêtre elle-même, pas seulement via les boutons de raccourci
-    actuels.
-  - Choix du thème clair/sombre dans la fenêtre -- actuellement forcé en
-    sombre (`ctk.set_appearance_mode("dark")`), cohérent avec
-    `display.html` mais pas ajustable par l'utilisateur comme le sont les
-    autres pages web.
-  - Couleur du bouton Quitter à revoir (actuellement neutre/transparent).
-- ~~**Récupération après plantage/redémarrage du serveur**~~ -- fait :
-  `MatchServer` persiste un instantané JSON de l'état du match
-  (`config/match_state.json`, jamais versionné) à chaque commande qui
-  change l'état et périodiquement pendant le décompte, et tente une
+- ~~**Journal applicatif persistant**~~ -- fait : `MatchServer` journalise
+  désormais chaque commande reçue, (dé)connexion, perte de connexion
+  réseau et message malformé dans un fichier avec rotation
+  (`logs/fletchtime.log`), en plus du journal déjà affiché dans la
+  fenêtre (en mémoire, perdu à la fermeture). Voir {doc}`architecture`,
+  section dédiée -- vérifié que le mot de passe ne s'y retrouve jamais.
+- ~~**Fenêtre graphique -- améliorations**~~ -- toutes faites (paramétrage
+  réseau, affichage des adresses, thème, couleur du bouton Quitter) :
+  - ~~Paramétrage du serveur et de l'adresse IP exposée~~ -- fait :
+    ports HTTP/WebSocket modifiables directement dans la fenêtre
+    (`config/gui.toml`), avec redémarrage automatique du serveur si les
+    ports changent pendant qu'il tourne. Objectif principal : plusieurs
+    salles de compétition sur un même PC -- copier le dossier FletchTime
+    une fois par salle (isole aussi `config/`, `logs/`, l'instantané de
+    récupération, donc des urgences bien séparées), donner des ports
+    différents à chaque copie, lancer chacune séparément. Testé
+    concrètement : deux instances simultanées sur le même processus,
+    ports différents, contenu totalement isolé entre les deux.
+  - ~~Affichage des adresses exposées~~ -- fait : champ dédié (adresse
+    d'accueil) dans la fenêtre elle-même, en plus des boutons de
+    raccourci -- utile pour retaper l'adresse à la main sur un appareil
+    sans bouton de raccourci. Non vérifié visuellement si le texte reste
+    bien sélectionnable/copiable une fois le champ désactivé (`CTkEntry`
+    n'a pas de vrai état "readonly" contrairement à `ttk.Entry`).
+  - ~~Choix du thème clair/sombre dans la fenêtre~~ -- fait : sélecteur
+    Système/Clair/Sombre dans l'en-tête, préférence persistée dans
+    `config/gui.toml` (jamais versionné, propre à la machine -- voir
+    `.gitignore`). Indépendant de `display.html`, qui reste lui, par
+    choix délibéré, toujours sombre.
+  - ~~Couleur du bouton Quitter à revoir~~ -- fait : couleur pleine
+    (`#3a4354`) au lieu de transparent+contour, visible sans être
+    alarmante (distincte du rouge d'Arrêter et du doré de Démarrer).
+- ~~**Récupération après plantage/redémarrage du serveur**~~ -- fait et
+  **confirmé en conditions réelles avec la v0.2.0** (synchronisation du
+  temps testée, plus de retour en arrière du chrono ; reconnexion
+  vérifiée) : `MatchServer` persiste un instantané JSON de l'état du
+  match (`config/match_state.json`, jamais versionné) à chaque commande
+  qui change l'état et périodiquement pendant le décompte, et tente une
   restauration silencieuse à la construction -- avant ça, un plantage en
   plein match perdait toute la progression (série, volée, temps écoulé).
   Voir {doc}`architecture`, section dédiée, pour le détail complet
-  (écriture atomique, repli silencieux sur un démarrage normal si la
-  reprise échoue).
+  (échéance en horloge murale pour un temps exact quelle que soit la
+  durée de l'indisponibilité, écriture atomique, repli silencieux sur un
+  démarrage normal si la reprise échoue).
 - ~~**Revamping du logo**~~ -- fait : nouveau logo cadran/flèche noir-or-blanc,
   wordmark "FletchTime" bicolore Fletch/Time, cohérent avec le thème clair/sombre.
 - ~~**Sécurisation cyber**~~ -- en partie fait : mot de passe optionnel
@@ -118,20 +141,16 @@ dépendent d'extensions compilées (Rust/C) peu fiables sur Pydroid 3, voir
   confirmée) -- voir le détail de l'investigation dans
   {doc}`dev-guide/index`. Pas de besoin utilisateur macOS avéré à ce jour ;
   à reconsidérer si ça change.
-- **Web app côté client (PWA)** : transformer `control.html`/`display.html`
-  (voire `index.html`) en Progressive Web App -- `manifest.json` + service
-  worker + icônes. Permettrait d'"installer" l'app sur l'écran d'accueil
-  d'une tablette/téléphone (lancement direct, sans retaper l'URL ni passer
-  par le navigateur), et de mettre en cache les fichiers statiques (HTML/CSS/
-  JS/logo) pour un chargement instantané même en cas de WiFi capricieux --
-  le WebSocket, lui, resterait bien sûr en temps réel, seul l'habillage
-  statique serait mis en cache. Chantier indépendant du reste, à ne traiter
-  qu'une fois l'interface stabilisée.
-- **Documentation Sphinx versionnée** : `docs.yml` publie aujourd'hui une
-  seule version de la doc sur GitHub Pages, écrasée à chaque nouveau tag
-  (voir plus bas pourquoi ce n'est plus à chaque push depuis peu) -- pas
-  de moyen de consulter la doc telle qu'elle était pour une release
-  précédente (ex. v0.1.2) si le code a changé depuis. À terme : une doc
-  par tag de version (ex. `/v0.1.2/`, `/v0.1.3/`) en plus d'une version
-  `/latest/`, avec un sélecteur de version dans le thème Furo (voir
-  `sphinx-multiversion` ou équivalent).
+- ~~**Web app côté client (PWA)**~~ -- abandonné délibérément : pas jugé
+  utile pour l'usage réel du club. (Aurait transformé
+  `control.html`/`display.html` en Progressive Web App -- installation
+  sur écran d'accueil, mise en cache des fichiers statiques.)
+- ~~**Documentation Sphinx versionnée**~~ -- abandonné délibérément : les
+  archives `.tar.gz` jointes à chaque Release GitHub suffisent pour
+  consulter la doc d'une version précédente, pas besoin d'un système de
+  versionnage complet côté GitHub Pages.
+- ~~**Termux / lancer FletchTime sur Android sans Pydroid**~~ -- abandonné
+  délibérément pour l'instant : usage réel actuel = téléphone en simple
+  client (accès réseau local), PC pour héberger le serveur. Pas de besoin
+  d'exécuter le serveur lui-même sur Android dans ces conditions. À
+  reconsidérer si l'usage change.

{fletchtime-0.2.0 → fletchtime-0.2.2}/src/fletchtime/__main__.py

@@ -28,10 +28,17 @@ from importlib import resources
 from pathlib import Path
 
 from fletchtime import __version__
+from fletchtime.logging_setup import configure_logging
 from fletchtime.runtime import ServerRuntime
+from fletchtime.server import config_store
 
-HTTP_PORT = 8000
-WS_PORT = 8765
+# Anciennement des constantes HTTP_PORT/WS_PORT figées ici -- les ports
+# par défaut vivent maintenant uniquement dans
+# config_store.DEFAULT_GUI_CONFIG, seule source de vérité (voir
+# _run_headless ci-dessous et fletchtime.gui, qui lisent tous deux
+# config_store.load_gui_config() plutôt qu'une constante figée). Permet
+# de faire tourner plusieurs salles de compétition sur un même PC : une
+# copie de dossier par salle, chacune avec son propre config/gui.toml.
 
 # Dossiers pré-remplis avec un contenu par défaut fourni avec FletchTime
 # (copié une seule fois, au tout premier lancement -- jamais écrasé
@@ -112,14 +119,14 @@ def local_ip() -> str:
         s.close()
 
 
-def _print_banner(ip: str, data_root: Path) -> None:
+def _print_banner(ip: str, data_root: Path, http_port: int) -> None:
     print("=" * 60)
     print(f"  FletchTime {__version__} -- serveur de contrôle et d'affichage")
     print(f"  FletchTime {__version__} -- control and display server")
     print("=" * 60)
-    print(f"  Accueil / Home      : http://{ip}:{HTTP_PORT}/")
-    print(f"  Contrôle / Control  : http://{ip}:{HTTP_PORT}/control.html")
-    print(f"  Affichage / Display : http://{ip}:{HTTP_PORT}/display.html?lane=1")
+    print(f"  Accueil / Home      : http://{ip}:{http_port}/")
+    print(f"  Contrôle / Control  : http://{ip}:{http_port}/control.html")
+    print(f"  Affichage / Display : http://{ip}:{http_port}/display.html?lane=1")
     print()
     print("  Depuis CET appareil, remplace l'IP par 127.0.0.1 si besoin.")
     print("  From THIS device, replace the IP with 127.0.0.1 if needed.")
@@ -152,9 +159,22 @@ def _run_headless() -> None:
     ensure_directories(data_root, app_web_dir)
     assets_dir = data_root / "web" / "assets"
 
-    _print_banner(local_ip(), data_root)
+    log_file = configure_logging(data_root / "logs")
+    print(f"Journal détaillé / Detailed log: {log_file}")
 
-    runtime = ServerRuntime(str(app_web_dir), str(assets_dir), HTTP_PORT, WS_PORT)
+    # Ports lus depuis config/gui.toml (mêmes préférences que la fenêtre
+    # graphique, voir config_store.load_gui_config) -- permet de faire
+    # tourner plusieurs salles de compétition sur le même PC : une copie
+    # de dossier par salle, chacune avec son propre gui.toml donnant des
+    # ports différents. "gui.toml" malgré le nom concerne aussi ce mode
+    # terminal, pour que les deux se comportent de façon cohérente.
+    gui_config = config_store.load_gui_config()
+    http_port = gui_config["http_port"]
+    ws_port = gui_config["ws_port"]
+
+    _print_banner(local_ip(), data_root, http_port)
+
+    runtime = ServerRuntime(str(app_web_dir), str(assets_dir), http_port, ws_port)
     runtime.start()
 
     stop_event = threading.Event()

{fletchtime-0.2.0 → fletchtime-0.2.2}/src/fletchtime/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.2.0'
-__version_tuple__ = version_tuple = (0, 2, 0)
+__version__ = version = '0.2.2'
+__version_tuple__ = version_tuple = (0, 2, 2)
 
-__commit_id__ = commit_id = 'g76ecfc7d6'
+__commit_id__ = commit_id = 'gceb71f360'

{fletchtime-0.2.0 → fletchtime-0.2.2}/src/fletchtime/engine/engine.py

@@ -71,7 +71,28 @@ class MatchEngine:
             # ce cas, le temps reste gelé tel quel.
             deadline = restore.get("wallclock_deadline")
             if deadline is not None:
-                self._time_left = max(0.0, deadline - time.time())
+                remaining = deadline - time.time()
+                if remaining <= 0:
+                    # Le temps réellement écoulé pendant l'indisponibilité
+                    # dépasse ce qui restait sur cette étape -- ne PAS se
+                    # contenter de figer time_left à 0 : le tick normal
+                    # suivant aurait alors déclenché le rattrapage
+                    # automatique de tick() (comportement volontaire et
+                    # préexistant, pensé pour un simple ralentissement
+                    # passager, pas une coupure de plusieurs secondes/
+                    # minutes) et avancé à l'étape suivante avec une durée
+                    # fraîche -- exactement ce qui ressemblait à "le
+                    # chrono repart" du point de vue des archers. Une
+                    # coupure trop longue pour être absorbée dans l'étape
+                    # en cours marque le match terminé : au responsable du
+                    # chronométrage de décider explicitement de la suite
+                    # (restart/goto), plutôt qu'une reprise automatique
+                    # qui devine une position dans une coupure qui a pu
+                    # durer n'importe combien de temps.
+                    self._finished = True
+                    self._time_left = 0.0
+                else:
+                    self._time_left = remaining
             # Pas d'appel à _emit_current_step_event() ici, volontairement :
             # une reprise après crash doit être silencieuse (pas de
             # prep_start/shoot_start rejoué comme si l'étape venait de