ok
cfb6680 parent: 3f0d339 added
docs/interface-cli-gui-architecture.md +45 -0 | new file mode 100644 | ||
| @@ -0,0 +1,45 @@ | ||
| 1 | +# Architecture d'interface de Régine : bibliothèque centrale, CLI, GUI | |
| 2 | + | |
| 3 | +Notes de conception sur la façon dont la logique métier de Régine (décrite dans `archivage-photo-elements-cles.md`) sera exposée à l'utilisateur, une fois le fonctionnement de l'application arrêté. | |
| 4 | + | |
| 5 | +## Principe général | |
| 6 | + | |
| 7 | +Une bibliothèque centrale porte toute la logique métier : import carte mémoire, checkout/réconciliation, structure de projet, métadonnées, intégrité. La CLI et l'interface graphique (GUI) sont deux façades minces au-dessus de cette bibliothèque, sans logique métier dupliquée de leur côté — chacune se contente d'appeler la bibliothèque et d'afficher/formatter le résultat. | |
| 8 | + | |
| 9 | +Justification : les enchaînements décrits dans les notes de conception (les quatre destinations possibles d'un import carte mémoire, la classification des changements à la réconciliation, la structure de projet par format) sont des séquences de décisions, pas de simples opérations CRUD. Les garder dans une seule bibliothèque évite que CLI et GUI divergent sur leur comportement. | |
| 10 | + | |
| 11 | +## Décisions actées | |
| 12 | + | |
| 13 | +- **Langage de la bibliothèque : Python.** Écosystème riche pour EXIF/IPTC/XMP (exiftool, pillow) et pour l'extraction d'aperçus RAW (rawpy), développement rapide, bien outillé pour ce domaine. | |
| 14 | +- **Mode d'exposition : import direct, un seul processus par lancement.** La CLI et la GUI importent la bibliothèque comme du code, chacune dans son propre processus à chaque exécution — pas de service/daemon permanent à installer, gérer ou superviser. | |
| 15 | +- **Concurrence multi-instances : déjà couverte, pas de mécanisme supplémentaire à construire.** La section 9 des notes de conception (workflow checkout/réconciliation) prévoit déjà un verrou/marqueur côté NAS pendant qu'un projet est "checké out", justement pour éviter que deux instances de Régine modifient le même projet en parallèle. Ce verrou remplit le rôle qu'un daemon central aurait pu jouer, sans en avoir la complexité de déploiement. | |
| 16 | + | |
| 17 | +## GUI : reportée, mais cadrée | |
| 18 | + | |
| 19 | +La GUI n'est pas construite dans l'immédiat, mais deux modes d'usage ont été identifiés pour la suite : | |
| 20 | + | |
| 21 | +1. **Tri/culling pendant l'édition** — sur un projet checké out en local : visualiser les photos, les sélectionner (promotion à la racine du projet). Deux limites observées avec DxO PhotoLab (section 11 des notes de conception) sont explicitement à corriger dans cette interface : l'absence d'association visuelle entre un RAW et son JPEG jumeau (à regrouper comme une seule entrée à l'écran même s'ils vivent dans des dossiers différents), et la navigation limitée au dossier courant (à remplacer par une vue combinée racine + sous-dossiers d'un même projet). | |
| 22 | + | |
| 23 | +2. **Consultation en lecture seule de l'archive** — parcourir l'archive sur le NAS sans passer par un checkout complet, typiquement pour retrouver et restaurer un fichier précis (ex. un RAW supprimé par erreur). Ce mode s'apparente à un navigateur/visualiseur au-dessus de l'archive, avec recherche (projet, date, texte) et une action de restauration vers un emplacement local — plus léger qu'un aller-retour complet avec manifeste et réconciliation. | |
| 24 | + | |
| 25 | +### Options techniques discutées pour la GUI (non tranchées) | |
| 26 | + | |
| 27 | +Le choix d'architecture "import direct en un seul processus" pèse sur l'option technique de la GUI : | |
| 28 | + | |
| 29 | +- **PySide6 (Qt natif Python)** — cohérent avec l'architecture choisie : la GUI importe la bibliothèque dans le même interpréteur, sans frontière de processus à gérer. Précédent solide dans le domaine (digiKam, RawTherapee sont construits sur Qt) pour une grille de miniatures performante, sélection clavier/souris, affichage de paires RAW+JPEG. Point faible : courbe d'apprentissage de Qt (Graphics View ou QML pour une grille fluide) et rendu jamais parfaitement natif à 100 % selon l'OS. | |
| 30 | +- **GUI web (HTML/CSS/JS)**, même packagée en appli desktop — casse partiellement le principe "un seul processus" : nécessite soit un mini-serveur local lancé/arrêté avec l'appli (deux processus OS couplés au cycle de vie, mais pas un vrai daemon), soit un pont plus lourd (PyO3, Tauri + sidecar). En échange, plus de flexibilité d'interface (CSS pour la grille, survol, glisser-sélectionner) et itération visuelle plus rapide. | |
| 31 | + | |
| 32 | +Inclination de départ vers PySide6 (cohérence architecturale + précédent dans des outils similaires), mais sans trancher : si l'itération rapide sur le visuel compte davantage, la voie web reste défendable. Décision à reprendre quand la GUI sera mise en chantier. | |
| 33 | + | |
| 34 | +## Prochaine étape proposée | |
| 35 | + | |
| 36 | +Poser les frontières de modules de la bibliothèque, dont la CLI et la (future) GUI seront toutes deux de simples clientes : | |
| 37 | + | |
| 38 | +- `metadata` — lecture/écriture IPTC/XMP/EXIF. | |
| 39 | +- `archive` — manifeste, hash, checkout/réconciliation. | |
| 40 | +- `import` — carte mémoire → projet. | |
| 41 | +- `project` — structure par format, sélection/promotion à la racine. | |
| 42 | +- `integrity` — hash à deux niveaux (fichier entier + image-only), scrub périodique. | |
| 43 | +- `camera_profile` — profil de boîtiers déclaré par l'utilisateur, désambiguïsation des sources à l'import. | |
| 44 | + | |
| 45 | +Cette découpe reste à valider et détailler (signatures de fonctions, objets d'échange, gestion des erreurs) avant de commencer l'implémentation de la CLI. | |
| new file mode 100644 | |||
| @@ -0,0 +1,45 @@ | |||
| 1 | +# Architecture d'interface de Régine : bibliothèque centrale, CLI, GUI | ||
| 2 | + | ||
| 3 | +Notes de conception sur la façon dont la logique métier de Régine (décrite dans `archivage-photo-elements-cles.md`) sera exposée à l'utilisateur, une fois le fonctionnement de l'application arrêté. | ||
| 4 | + | ||
| 5 | +## Principe général | ||
| 6 | + | ||
| 7 | +Une bibliothèque centrale porte toute la logique métier : import carte mémoire, checkout/réconciliation, structure de projet, métadonnées, intégrité. La CLI et l'interface graphique (GUI) sont deux façades minces au-dessus de cette bibliothèque, sans logique métier dupliquée de leur côté — chacune se contente d'appeler la bibliothèque et d'afficher/formatter le résultat. | ||
| 8 | + | ||
| 9 | +Justification : les enchaînements décrits dans les notes de conception (les quatre destinations possibles d'un import carte mémoire, la classification des changements à la réconciliation, la structure de projet par format) sont des séquences de décisions, pas de simples opérations CRUD. Les garder dans une seule bibliothèque évite que CLI et GUI divergent sur leur comportement. | ||
| 10 | + | ||
| 11 | +## Décisions actées | ||
| 12 | + | ||
| 13 | +- **Langage de la bibliothèque : Python.** Écosystème riche pour EXIF/IPTC/XMP (exiftool, pillow) et pour l'extraction d'aperçus RAW (rawpy), développement rapide, bien outillé pour ce domaine. | ||
| 14 | +- **Mode d'exposition : import direct, un seul processus par lancement.** La CLI et la GUI importent la bibliothèque comme du code, chacune dans son propre processus à chaque exécution — pas de service/daemon permanent à installer, gérer ou superviser. | ||
| 15 | +- **Concurrence multi-instances : déjà couverte, pas de mécanisme supplémentaire à construire.** La section 9 des notes de conception (workflow checkout/réconciliation) prévoit déjà un verrou/marqueur côté NAS pendant qu'un projet est "checké out", justement pour éviter que deux instances de Régine modifient le même projet en parallèle. Ce verrou remplit le rôle qu'un daemon central aurait pu jouer, sans en avoir la complexité de déploiement. | ||
| 16 | + | ||
| 17 | +## GUI : reportée, mais cadrée | ||
| 18 | + | ||
| 19 | +La GUI n'est pas construite dans l'immédiat, mais deux modes d'usage ont été identifiés pour la suite : | ||
| 20 | + | ||
| 21 | +1. **Tri/culling pendant l'édition** — sur un projet checké out en local : visualiser les photos, les sélectionner (promotion à la racine du projet). Deux limites observées avec DxO PhotoLab (section 11 des notes de conception) sont explicitement à corriger dans cette interface : l'absence d'association visuelle entre un RAW et son JPEG jumeau (à regrouper comme une seule entrée à l'écran même s'ils vivent dans des dossiers différents), et la navigation limitée au dossier courant (à remplacer par une vue combinée racine + sous-dossiers d'un même projet). | ||
| 22 | + | ||
| 23 | +2. **Consultation en lecture seule de l'archive** — parcourir l'archive sur le NAS sans passer par un checkout complet, typiquement pour retrouver et restaurer un fichier précis (ex. un RAW supprimé par erreur). Ce mode s'apparente à un navigateur/visualiseur au-dessus de l'archive, avec recherche (projet, date, texte) et une action de restauration vers un emplacement local — plus léger qu'un aller-retour complet avec manifeste et réconciliation. | ||
| 24 | + | ||
| 25 | +### Options techniques discutées pour la GUI (non tranchées) | ||
| 26 | + | ||
| 27 | +Le choix d'architecture "import direct en un seul processus" pèse sur l'option technique de la GUI : | ||
| 28 | + | ||
| 29 | +- **PySide6 (Qt natif Python)** — cohérent avec l'architecture choisie : la GUI importe la bibliothèque dans le même interpréteur, sans frontière de processus à gérer. Précédent solide dans le domaine (digiKam, RawTherapee sont construits sur Qt) pour une grille de miniatures performante, sélection clavier/souris, affichage de paires RAW+JPEG. Point faible : courbe d'apprentissage de Qt (Graphics View ou QML pour une grille fluide) et rendu jamais parfaitement natif à 100 % selon l'OS. | ||
| 30 | +- **GUI web (HTML/CSS/JS)**, même packagée en appli desktop — casse partiellement le principe "un seul processus" : nécessite soit un mini-serveur local lancé/arrêté avec l'appli (deux processus OS couplés au cycle de vie, mais pas un vrai daemon), soit un pont plus lourd (PyO3, Tauri + sidecar). En échange, plus de flexibilité d'interface (CSS pour la grille, survol, glisser-sélectionner) et itération visuelle plus rapide. | ||
| 31 | + | ||
| 32 | +Inclination de départ vers PySide6 (cohérence architecturale + précédent dans des outils similaires), mais sans trancher : si l'itération rapide sur le visuel compte davantage, la voie web reste défendable. Décision à reprendre quand la GUI sera mise en chantier. | ||
| 33 | + | ||
| 34 | +## Prochaine étape proposée | ||
| 35 | + | ||
| 36 | +Poser les frontières de modules de la bibliothèque, dont la CLI et la (future) GUI seront toutes deux de simples clientes : | ||
| 37 | + | ||
| 38 | +- `metadata` — lecture/écriture IPTC/XMP/EXIF. | ||
| 39 | +- `archive` — manifeste, hash, checkout/réconciliation. | ||
| 40 | +- `import` — carte mémoire → projet. | ||
| 41 | +- `project` — structure par format, sélection/promotion à la racine. | ||
| 42 | +- `integrity` — hash à deux niveaux (fichier entier + image-only), scrub périodique. | ||
| 43 | +- `camera_profile` — profil de boîtiers déclaré par l'utilisateur, désambiguïsation des sources à l'import. | ||
| 44 | + | ||
| 45 | +Cette découpe reste à valider et détailler (signatures de fonctions, objets d'échange, gestion des erreurs) avant de commencer l'implémentation de la CLI. | ||