Ortho4XP V3 — mise à jour

[domisilasol]

Pour en revenir aux fichiers log, il faudrait dans l'idéal fonctionner avec 2 fichiers log :

--> Ortho4xp_install.log
qui enregistre tous les messages lors de l'installation

--> Ortho4XP.log
qui enregistre tous les messages lors de l'utilisation de Ortho4XP, quelque soit la fenêtre active en cours d'exécution, y compris les messages dans les fenêtre secondaires.

--> ces 2 fichiers doivent se trouver à la racine de ORTHO4XP_V3

A+

[Ypsos]

Fichier Ortho4XP.log égaré : tu avais raison, il partait dans le dossier de l'extent au lieu de la racine. C'était dû à un chemin relatif dans la journalisation. C'est corrigé : le log revient toujours à la racine d'Ortho4XP, quel que soit le dossier de travail.


A+?

[Ypsos]

Pour en revenir aux fichiers log, il faudrait dans l'idéal fonctionner avec 2 fichiers log :

--> Ortho4xp_install.log
qui enregistre tous les messages lors de l'installation

--> Ortho4XP.log
qui enregistre tous les messages lors de l'utilisation de Ortho4XP, quelque soit la fenêtre active en cours d'exécution, y compris les messages dans les fenêtre secondaires.

--> ces 2 fichiers doivent se trouver à la racine de ORTHO4XP_V3

A+

Merci pour la suggestion des deux fichiers log, elle était pertinente. Voici où ça en est.

Les deux logs existent bien, tous les deux à la racine d'ORTHO4XP_V3 :

1) Log d'installation — ortho4xp_install.log
Il enregistre les messages lors de l'installation des prérequis. Il est écrit par le module d'installation et ne se met à jour que lors d'une installation/mise à jour (pas à chaque lancement), ce qui est normal pour un log d'install.

2) Log de fonctionnement — Ortho4XP.log
C'est celui-ci qui a été corrigé et amélioré :
- Il est désormais toujours écrit à la racine du projet (avant, dans certains cas comme la création d'extent, il pouvait partir dans le dossier de travail en cours — c'est corrigé).
- Il est maintenant unifié : un collecteur, activé automatiquement à chaque lancement (aucun bouton à penser à activer), intercepte les messages et les rassemble dans ce seul fichier, quel que soit le module qui les produit.
- Les messages de fenêtres secondaires qui écrivaient uniquement dans leur propre cadre (ex. le Générateur d'Extent) sont maintenant repris dans le fichier. Testé en réel : la création d'un extent apparaît bien dans Ortho4XP.log à la racine.

Un point de transparence : certaines fenêtres utilisent une simple barre de statut (messages qui se remplacent au fil de l'eau) plutôt qu'un vrai journal. Je ne les ai pas forcées dans le log pour l'instant, pour éviter de le noyer sous des messages de progression. Si le besoin s'en fait sentir avec les retours, ça pourra être ajouté au cas par cas.

Petit détail : le fichier d'install s'appelle ortho4xp_install.log (en minuscules) ; je ne l'ai pas renommé, il fonctionne tel quel.

En résumé : deux logs, tous deux à la racine, celui de fonctionnement corrigé et unifié.

A+?

[domisilasol]

Salut Ypsos

je te soumets ma réflexion sur la création des fichiers .comb (dans un but de simplifier et clarifier l'interface).

1°) Dans la fenêtre "Avancé" :

- supprimer le bouton "Générer un .comb - mode expert"
les 2 sous options proposées ne sont pas fonctionnelles ! (pas claires et pas utiles)

- Garder le bouton "Relier mes extents aux providers (.comb)


2°) Dans le fenêtre "Relier mes extents aux providers (.comb) :

- ajouter un champ pour saisir et afficher le nom du fichier .comb en cours d'édition

- ajouter un bouton pour charger un fichier .comb existant

- supprimer le bouton "Créer un provider (.lay)"
-> la création d'un provider .lay se fait à partir de la fenêtre "Avancé"
-> redondance pas utile à mon avis

- le bouton "Proposer depuis les extents" peut être gardé
-> cela oblige ensuite à supprimer les lignes inutiles
-> peut être fastidieux si beaucoup d'extents
-> mais peut être utile si peu d'extents

- le bouton "Ajouter une ligne" à garder
-> la ligne ajoutée est pratique, donc garder le format

- le bouton "Editeur de texte" à garder (pour les experts)

- le bouton "Aperçu" peut être conservé

- le bouton "Générer" renommé en "Sauvegarder"

Ainsi modifiée, la fenêtre a tout ce qu'il faut à mon avis pour créer/éditer/modifier les fichiers .comb,
pas besoin d'autres fenêtres qui viendraient compliquer la compréhension.

Ton avis ?

A+


?

[Ypsos]

a supprimer duplicata

[Ypsos]

Domisilasol - Salut Ypsos

je te soumets ma réflexion sur la création des fichiers .comb (dans un but de simplifier et clarifier l'interface).

1°) Dans la fenêtre "Avancé" :

- supprimer le bouton "Générer un .comb - mode expert"
les 2 sous options proposées ne sont pas fonctionnelles ! (pas claires et pas utiles)

- Garder le bouton "Relier mes extents aux providers (.comb)


2°) Dans le fenêtre "Relier mes extents aux providers (.comb) :

- ajouter un champ pour saisir et afficher le nom du fichier .comb en cours d'édition

- ajouter un bouton pour charger un fichier .comb existant

- supprimer le bouton "Créer un provider (.lay)"
-> la création d'un provider .lay se fait à partir de la fenêtre "Avancé"
-> redondance pas utile à mon avis

- le bouton "Proposer depuis les extents" peut être gardé
-> cela oblige ensuite à supprimer les lignes inutiles
-> peut être fastidieux si beaucoup d'extents
-> mais peut être utile si peu d'extents

- le bouton "Ajouter une ligne" à garder
-> la ligne ajoutée est pratique, donc garder le format

- le bouton "Editeur de texte" à garder (pour les experts)

- le bouton "Aperçu" peut être conservé

- le bouton "Générer" renommé en "Sauvegarder"

Ainsi modifiée, la fenêtre a tout ce qu'il faut à mon avis pour créer/éditer/modifier les fichiers .comb,
pas besoin d'autres fenêtres qui viendraient compliquer la compréhension.

Ton avis ?

A+
?

Je suis bloqué jusqu'à Mardi 21h00.

Néanmoins j'ai pu avanbcer sur tes propositions avec Claude et voici son annalyse et proposition en considération des sécurités que je lui ai mis en place pour qu'il ne casse rien.

Le point clé que le code révèle


La fonction que le forumeur veut ajouter à la fenêtre « Relier mes extents » (« Charger un .comb existant ») existe déjà — elle est dans le « mode expert » qu'il veut supprimer. C'est run_comb_corriger (Ch.9) : import d'un .comb + tableau éditable ligne à ligne, qui gère même les noms longs (EXCEPTION_FRANCE_…, FRANCE_Ortho-Litto-…).

Donc supprimer bêtement le bouton « mode expert » ferait perdre exactement la capacité qu'on veut gagner. La bonne action n'est pas « supprimer » mais fusionner : rapatrier le « Charger » de run_comb_corriger dans run_comb_assembler. Cartographie

Ch.1 à 5 + Ch.7 (scan, SelectionComb, valider_selection, construire_texte_comb, ecrire_comb, parser_lignes_comb, importer_comb, scanner_extents)	O4_comb_generator.py	Moteur .comb — lecture, validation, écriture avec garde-fous ZonePhoto/.bak, import	À CONSERVER intact — on n'y touche pas
run_comb_assembler (Ch.8)	idem	Fenêtre « Relier mes extents »	À ENRICHIR — devient la fenêtre unique
run_comb_corriger (Ch.9) — logique d'import	idem	Charger un .comb + tableau éditable	À FUSIONNER dans l'assembleur (c'est le « Charger » demandé)
run_comb_creer (Ch.6) — liste de providers à cocher	idem	Créer un .comb en cochant des providers	SUPPRIMABLE de l'UI, gardé dans le code. Le flux « Proposer depuis les extents » + lignes manuelles couvre le besoin courant
run_comb_generator (Ch.9) — écran de choix	idem	Aiguillage creer / corriger	Plus appelé par le menu, gardé dans le module (compat/tests)
Bouton « Générer un .comb — mode expert »	O4_Menu_Avance.py(liste boutons, item 2)	Ouvre l'écran de choix	SUPPRIMABLE de l'UI (retirer une ligne de la liste)
Bouton « Créer un provider (.lay) » dans les fenêtres .comb	_creer_lay (Ch.6 et Ch.8)	Raccourci vers run_lay_generator	À DÉPLACER — retirer le bouton, .lay reste dans « Avancé ». O4_lay_generator intact
« Proposer depuis extents », « Ajouter une ligne », « Aperçu », « Éditeur texte »	Ch.8	—	À CONSERVER
« Générer »	Ch.8	Appelle ecrire_comb(écrit le fichier)	À RENOMMER « Sauvegarder » — vérifié : il ne fait qu'écrire + garde-fous, le renommage est cohérent
Champ nom de fichier	absent de Ch.8 (sortie figée Provider_Extents.comb)	—	À AJOUTER. Note : ecrire_combprotège déjà ZonePhoto.comb — le garde-fou ne dépend pas du nom figé, on peut donc le rendre éditable sans risque

La seule vraie décision technique


Aujourd'hui, dans l'assembleur (Ch.8), les colonnes Provider et Extent sont des listes déroulantes figées (readonly). Si on y charge un EUR.comb dont un provider ou une zone n'est pas dans les listes, la case ne peut pas afficher la valeur ? perte de données. C'est précisément le bug que tu avais déjà rencontré (« l'ancien bouton Importer qui cochait dans la liste figée a été retiré »).

À l'inverse, run_comb_corriger utilise des champs de saisie libre — c'est pour ça qu'il ne perd aucun nom long.

Conclusion : pour avoir dans une seule fenêtre à la fois « Proposer depuis les extents » (force de l'assembleur) et « Charger un .comb » sans perte, les lignes doivent devenir éditables (saisie libre assistée d'une liste déroulante), pas figées. C'est le vrai choix de conception de ce chantier.

Valides-tu cette direction — fusionner le « Charger » de run_comb_corriger dans l'assembleur avec des lignes en saisie libre — pour que je te prépare le plan d'implémentation détaillé (toujours avant tout code) ?
?

cette piste va dans ton sens en partie au moins?

[domisilasol]

un petit commentaire sur :

Aujourd'hui, dans l'assembleur (Ch.8), les colonnes Provider et Extent sont des listes déroulantes figées (readonly). Si on y charge un EUR.comb dont un provider ou une zone n'est pas dans les listes, la case ne peut pas afficher la valeur ? perte de données. C'est précisément le bug que tu avais déjà rencontré (« l'ancien bouton Importer qui cochait dans la liste figée a été retiré »).?

oui, ce que j'attendrais pour les champs Provider et Extent c'est une liste déroulante figée, avec les Providers et Extents présents sur la machine.
Dans le cas où on charge un fichier TOTO.comb avec des Providers ou Extents non présents, les cases restent vides.
=> on garde la cohérence avec ce que l'utilisateur lambda a sur sur ordi.

Pour sécuriser, on peut empêcher de sauvegarder, si il y a des lignes avec Provider ou Extent vides.
Pour pouvoir sauvegarder, il faut supprimer ou modifier les lignes concernées ( et changer de nom du fichier .comb si on veut garder l'ancienne version)
=> ainsi le fichier .comb original n'est pas écrasé et le nouveau est opérationnel pour l'utilisateur lamda.

Si tu as besoin d'éditer à la main un Provider ou un Extent non présent dans la liste déroulante, tu passe par le bouton "Editeur de texte", c'est fait pour ça

[Ypsos]

Je comprends tout à fait ta logique : laisser les cases vides, bloquer la sauvegarde et utiliser l'éditeur de texte pour les exceptions permet effectivement de sécuriser le fichier et de garantir la cohérence avec la machine.

Cependant, ma philosophie sur ce point est différente : un utilisateur lambda ne devrait plus avoir à s'embêter à passer par un éditeur de texte externe.

Tout doit pouvoir se gérer de manière fluide directement dans l'interface graphique pour lui faciliter le travail.

L'éditeur de texte doit rester un outil avancé, strictement réservé à l'expert qui sait ce qu'il fait.

Au lieu de laisser l'iutilisateur de base face à des cases vides qui bloquent la sauvegarde, l'idéal serait de réfléchir à une solution pour mieux l'accompagner et automatiser cette gestion au sein de l'IHM.

On conserve ton idée de ne pas écraser le fichier original, mais on lui propose une interface pour modifier les lignes concernées sans jamais quitter l'application.

Depuis mars 2026, où je modernise avec Claude ORTHO4X, mon approche a toujours été de le faire coder un usage pour utilisateur lambda, user-friendly.

Aussi, effectivement je pense qu'il faut que je demande a Claude de faire évoluer l'interface pour guider l'utilisateur lambda dans cette correction (par exemple avec une réattribution assistée des champs manquants) tout en gardant ce niveau de sécurité et laisser le choix à l'expert ??

[domisilasol]

Je comprends que tu as un besoin spécifique.

Si tu as besoin des champs éditables, une solution peut être de conserver alors dans la fenêtre "Avancé" le bouton "Générer un .comb - mode expert", et conserver les 2 sous options.

Mais pour un utilisateur lambda, je pense qu'il faut plutôt envisager ce que je propose pour la fenêtre "Relier mes extents aux providers (.comb)", avec des listes déroulantes non éditables (voir message plus haut).

Plutôt que "Sauvegarder", envisager plutôt "Enregistrer" (plus familier pour le quidam Ouvrir / Enregistrer"

A+

[Ypsos]

Je pense que ce qu'on pourrait faire,

conserver dans le menu outil avancé, Générer un .comb-- mode expert . Une fois qu'on a cliqué sur le bouton une interface à double choix, s'ouvre .

Utilisation automatisée et Utilisation expert (à définir terminologie).

En fonction de l'usage, l'utilisation automatisée doit intégrer

- l'option Relier mes extents aux providers (.comb)", avec des listes déroulantes non éditables . il faut que relier mes experts et ce qui se passe actuellement dans un compte soit pour l'utilisateur de base entièrement automatisé

-l'option Créer module lay avec des listes déroulantes non éditables . il faut que relier mes experts et ce qui se passe actuellement dans un compte soit pour l'utilisateur de base entièrement automatisé

- les patches et le fitres avec des listes déroulantes non éditables . il faut que relier mes experts et ce qui se passe actuellement dans un compte soit pour l'utilisateur de base entièrement automatisé ( oui Non sauf si appel aurre endroit a vérifier)

- aider ordre automatisé des priorités (codage sur quel critère a définir?)

Ety poruy : Utilisation expert (

Sélection éditeur de texte bie entendu en un seul fichier et pour le mode expert mettre la rubrique expert dans cette interface et ajouter ce que tu aurais envie de toi de voir pour ajouter. tu peux peaufiner la réponse, on a encore un petit peu de temps pour conserver le dialogue et voir comment améliorer cette interfaces tant pour les utilisateurs que pour les 'expert tu en penses quoi ?

Je préfère qu'on soit au clair avant de codage, car le codage use, du quota.

Je savais que une fois mes idées codées dans les modules, les premiers bugs corrigés vers la fin, il fallait s'occuper de l'ergonomie générale c'est qu'on est en train de faire maintenant. Merci pour le retour.

[domisilasol]

Je t'ai donné mon avis et fait mes propositions (d'un utilisateur lambda) pour faire avancer le projet.

Peut-être d'autres utilisateurs ont des avis différents ?

Tu as tes propres contraintes et souhaits en tant que pilote de ce projet, c'est à toi de choisir et faire au mieux

Bon courage

[Ypsos]

On va attendre jusqu'à demain mardi 21 heures le redémarrage de Claude , le retour d'autres utilisateurs et leur avis.

Je ferai un cahier de charges sur ces retours et de ma réflexion et on va faire un mixte de tout et demander Claude de coder ce mixte

[Ypsos]

Re bonjour domisilasol,

Après réflexion et étude de diverses pistes, je reviens à mon idée précédente, en intégrant tes propositions de sécurité et leurs implications.


Je réfléchis donc à une solution mixte, avec une volonté de **simplifier fortement l'interface sans supprimer les possibilités avancées**.

L'idée que j'envisage actuellement serait la suivante :

**Outils avancés ? Gestion des fichiers .comb**

Puis une interface très simple proposant deux possibilités :

### 1. Gestion automatisée

Ce serait le parcours destiné à l'utilisateur non expert.

L'objectif serait que tout ce qui peut être automatisé le soit, sans lui demander de connaître la structure interne des fichiers :

* **Relier mes extents aux providers (.comb)**
* **Créer le module .lay**
* **Gérer automatiquement les patches**
* **Gérer automatiquement les filtres**
* **Proposer automatiquement un ordre de priorité lorsque cela est possible**
* Utiliser uniquement des listes déroulantes correspondant aux Providers et Extents réellement présents sur la machine
* Guider l'utilisateur lorsqu'un élément d'un ancien fichier n'existe plus sur son installation

Autrement dit, pour l'utilisateur non expert, **les .comb, .lay, patches, filtres et priorités feraient partie d'un même parcours automatisé**, plutôt que d'être présentés comme plusieurs outils techniques indépendants.

Par exemple, si un `.comb` chargé contient un Provider ou un Extent qui n'existe pas sur la machine, je préfère éviter que l'utilisateur soit simplement confronté à une case vide et à un message incompréhensible.

L'application pourrait plutôt lui proposer une correction assistée : remplacer par une correspondance disponible, supprimer la ligne concernée, ou lui expliquer clairement pourquoi cette ligne ne peut pas être utilisée.

L'idée est donc de conserver ta sécurité, mais de faire en sorte que **l'utilisateur non expert puisse résoudre le problème directement dans l'IHM**, sans devoir ouvrir un éditeur de texte.

### 2. Gestion experte

Pour l'utilisateur qui connaît la structure des `.comb`, je conserverais en revanche les possibilités de contrôle manuel :

* édition complète des lignes ;
* gestion des Providers / Extents particuliers ;
* gestion manuelle des patches et filtres ;
* gestion des priorités ;
* import/export ;
* aperçu ;
* et bien entendu l'éditeur de texte.

L'éditeur de texte resterait donc bien un outil expert, comme tu le proposais.

Cela permettrait de ne pas imposer la complexité à l'utilisateur non expert, tout en ne supprimant aucune possibilité pour celui qui en a réellement besoin.

Je pense également que le terme **« Enregistrer »** est effectivement plus naturel que « Générer » lorsqu'on travaille sur un fichier existant. Je retiens donc plutôt cette terminologie.

Pour résumer ma réflexion actuelle :

**ton approche apporte la simplicité et la sécurité pour l'utilisateur non expert ; la partie experte permet de conserver la souplesse nécessaire pour les cas particuliers.**

Je cherche donc à faire en sorte que les deux ne se mélangent pas dans la même interface et ne viennent pas compliquer l'utilisation quotidienne.


Merci en tout cas pour tes remarques : elles m'ont permis de mieux cerner ce qu'il faut simplifier pour l'utilisateur non expert, tout en réfléchissant à la manière de ne pas perdre les possibilités utiles aux utilisateurs plus avancés.

A+
Ypsos
?

[lebelge]

Salut Ypsos,

Je suis toujours avec attention tes développements (avec ton nouveau copain Claude) et si l'idée de faire d'Ortho4XP une application « idiot-proof » (ou, plus poliment, « user-friendly ») avec une installation simple et une interface entièrement revue pour une meilleure convivialité, le pari était tenu.

Mais depuis, à vouloir en faire toujours plus, et encore plus, pour exploiter toutes les fonctionnalités « cachées » de cette application géniale que nous a offerte Oscar-Pilot, je crains que tu ne perdes tout l'intérêt du départ : en faire une application à la portée de tous.

Le fait que tu reviennes vers « ** simplifier fortement l'interface sans supprimer les possibilités avancées ** » est une excellente idée. Je te souhaite vraiment un joli succès avec ton travail. Tu peux déjà voir la lumière au fond du tunnel. Plus que quelques tests encore et tu pourras (enfin) sortir une version finale qui fera le plaisir de beaucoup de monde ici.

Bon courage. Tu reviens dans le bon sens.

lebelge?

[Ypsos]

Merci pour le soutien.

Vu les contraintes de quotas avec Claude, j'ai dû structurer mon travail en plusieurs phases distinctes :

• Première phase : nettoyage, correction des anciens bugs et des lignes fantômes, puis adaptation d'Ortho4XP à Python 3.12 tout en anticipant la version 3.14 (qui attendra que certains modules tiers soient totalement optimisés).
• Seconde phase : création des nouveaux modules et des options associées.
• Troisième phase : phase de test et analyse des retours pour évaluer l'impact d'éventuelles modifications ou suppressions de modules.
• Quatrième phase : correction des bugs signalés par les utilisateurs.

Les retours s'étant raréfiés ces quinze derniers jours, j'ai pu lancer deux chantiers : la rédaction d'un guide pas à pas en PDF pour les modules et la refonte de l'ergonomie, nourrie par nos échanges sur le forum. Grâce aux contributions et aux témoignages des uns et des autres sur ces espaces, Ortho devrait réussir à aller dans le sens attendu par les utilisateurs depuis la sortie de la version 1. Bon, avec 20 ans de retard à rattraper, c'est compliqué, mais dans la limite des possibilités techniques, cet objectif devrait pouvoir être atteint ! Un grand merci à vous, car sans cela, Ortho ne serait pas ce qu'il est.

Claude sera de nouveau disponible ce soir à 21h00.

Certes, la bêta était encore loin d'être user-friendly, mais je ne voulais pas gaspiller de quota en concevant une interface définitive alors que la structure des modules pouvait encore bouger.

Maintenant que ces aspects techniques sont derrière nous, cette semaine sera entièrement dédiée à l'ergonomie, en commençant par le module évoqué avec Domisilasol.


Concernant les nouveaux modules créés, il est tout à fait possible de les rendre user-friendly puisqu'ils partent d'une feuille blanche.

La vraie question concerne l'interface de base d'Ortho et ses fenêtres historiques.

Souhaitez-vous que l'on réfléchisse ensemble à une approche plus conviviale de cette interface principale et de ses fenêtres historiques?

Sachez que cela impliquerait de toucher aux fichiers de base d'Ortho4XP, ce qui comporte des risques techniques non négligeables, mais reste tout à fait faisable si l'on souhaite aller au bout de la démarche.

Qu'en pensez-vous ? Faut-il s'attaquer à ce chantier historique ou capitaliser uniquement sur la simplification des nouveaux ajouts ?
?