Numérotation des longueurs: on fait quoi ?

#41

Piece of cake (pardon cheese :grin: )

Oui pour la Proposition #2

@Modo_Topo_FR_contact

1 Like
#42

Je rappelle le lien :

Proposition #2

#43

Ok pour moi.

#44

OK pour moi aussi

#45

OK pour moi itou.

#46

Moi, aussi, je suis d’accord avec tout ce peut améliorer rapidement cette numérotation des longueurs ; et s’il y a des corrections manuelles à faire, je suis disponible.

#47

Je ne suis pas utilisateur des balises L#, je vous fait confiance mais j’ai l’impression que cette solution simplifie la tache sans réduire les possibilités essentielles: que du bon !

#48

OK pour moi aussi !
Et si ça prend un peu de temps de tout coder, peut-être prévoir une 1ère mise en prod avec les plus faciles, qui vont déjà décoder un certain nb d’iti supplémentaires, avant de faire les plus complexes.

2 Likes
#49

Merde, je vais devoir le café:smiley:
Très bien!

#50

Je suis contre.
Il n’y a pas d’interface d’édition confortable actuellement.
Autoriser les retours lignes entre les cellules permet d’aérer le code à l’édition, c’est plus facile de s’y retrouver.
De la même façon, on peut sauter une ligne entre les longueurs sans que ça crée un nouveau tableau.

Pour le lecteur, permettre un retour ligne dans le texte d’une cellule permet de mettre une info concernant toute la longueur mais à la fin de la description, tout en étant mieux visible qu’en la mettant tout à la fin (après la description du relais, qu’on ne lit pas tout de suite).

Exemple :
Il vaut mieux :

Remonter le couloir à gauche du gendarme jusqu’au pied du dièdre. Il comporte plusieurs ressauts athlétiques (un anneau de corde en place) avec des rétablissement délicats (replats avec pierres). R3 possible au fond du couloir ou sur un gros becquet un peu plus haut (sangle en place).
Attention, il y a parfois un nid de guêpes à proximité du dièdre.

que :

Remonter le couloir à gauche du gendarme jusqu’au pied du dièdre. Il comporte plusieurs ressauts athlétiques (un anneau de corde en place) avec des rétablissement délicats (replats avec pierres). R3 possible au fond du couloir ou sur un gros becquet un peu plus haut (sangle en place). Attention, il y a parfois un nid de guêpes à proximité du dièdre.

Dans le 1er cas, l’info sur le nid de guêpes est toujours en début de ligne, quel que soit la largeur de l’écran.

Ceci implique qu’il faille une ligne vide avant et après un bloc de longueurs pour le séparer du texte normal.
C’est la même contrainte que pour les listes à puces. C’est cohérent d’avoir le même fonctionnement entre une liste de longueurs et une liste à puce ou une liste numérotée.

#51

Je recopie ici la réponse que j’ai donné pour la meme question sur le forum interne :

une ligne de tableau L# sera codée sur une unique ligne, en effet potentiellement assez longue. Si tu veux avoir un retour à la ligne en rendu, tu devras mettre le code <br>.

Exemple, en prenant un cas ou ca sera bien plus chiant pour le rédacteur (imagine que le contenu est bien plus long) :

Avant :

    L# 
    | Cellule 1 
    | Cellule 2 
    | Cellule 3 avec
    Un retour à la ligne
    |Cellule 4
     
    L#  
    | Cellule 1 
    | Cellule 2 
    | Cellule 3 avec
    Un retour à la ligne
    |Cellule 4

Après :

    L#  | Cellule 1 | Cellule 2 | Cellule 3 avec <br> Un retour à la ligne |Cellule 4
    L#  | Cellule 1 | Cellule 2 | Cellule 3 avec <br> Un retour à la ligne |Cellule 4

Le reste du code n’est pas concerné.

Pourquoi je pense que ce choix une bonne solution :

  1. C’est certes plus chiant pour le contributeur, mais fonctionnellement, on ne perd rien
  2. Ca n’est pas une voie sans retour, on pourra toujours recoder cette possibilité un jour.
  3. Mais surtout, le parseur sera beaucoup plus simple à faire. Pour moi, la top prio est d’avoir des topos lisibles. J’ai du coder ce truc pour CampUI, et je pense que ce retour à la ligne représente 30% de la complexité, pour juste un peu de confort de rédaction. Le jeu n’en vaut pas la chandelle.

Tout cela dit, c’est Olivier qui s’y colle, si il se sent de le faire, il peut aussi donner son avis.

Mais mon avis, dans l’absolu, c’est keep it simple : même si quelqu’un se propose de coder ce retour à la ligne, pour la pérennité de camptocamp, on ne doit surtout pas le faire.

#52

Je rejoins @Bubu, autant que possible il faut keep it simple pour le contributeur. Ce <br> n’est pas intuitif et dans aucun doc de mise en page actuellement …

#53

C’est le « autant que possible » ou ça coince. Les personnes qui ont essayé de porter le parseur V5 sur la V6 n’ont pas réussi. Et c’est à cause de ça qu’on a des topos illisibles depuis un an, et encore pour un bout de temps.

Pour être clair, je trouve même que ma seconde proposition est encore trop complexe au vu de notre capacité de dev, car un seul développeur occasionnel maîtrisera ce code, c’est bien trop peu.

Si nous n’étions pas sur un projet collaboratif, et si j’étais chef de projet et que mon job en dépendrai, ce serait clairement la première proposition que je choisirai, et il n’y aurait pas de discussion possible :slight_smile:

2 Likes
#54

OK, je suis aussi pour une solution rapide même avec une petite perte de qualité plutôt que trainer des L# pendant des années …

#55

Idem, il faut avancer sur le problème. Ca fait bientôt une année que c’est en attente, et la solution proposée par @CharlesB est mieux que ce qui a été proposé (ou pas) jusqu’a présent.
De toute façon on voit bien que le système est trop compliqué et impossible en l’état de le maintenir et surtout de le faire evoluer simplement.
Après si il y a 1000 itinéraires (qui sont quand même des cas particuliers) « moches » mais que ca resout le problème des 18000 autres, il faut privilegier la lisibilité de ce que recherche la majorité des contributeurs.

1 Like
#56

Il faut quand même relativiser : actuellement, il y a au moins 9000 itinéraires qui s’affichent correctement sur les 14000 qui comportent du L#.
Juste en remplaçant les :: , il y en aurait 1000 de plus.

#57

Oui il faut avancer sur ce sujet et la derniere proposition de Charles semble un bon composition: on conserve une bonne partie des balises existantes. Et pour les quelques contributeurs qui ont besoin de faire des retours à la ligne dans une cellule, ils se contenteront du br, tant pis si ce n’est pas le top de l’ergonomie.

5 Likes
#58

Hello à tous,

Si je récapitule les retours de chacun sur la proposition 2, (merci de me corriger si j’ai sur-interprété vos propos) :

  • Pour : Loic_P, Chti.nain, Borut, Tintin, Miko, Rob.Bonnet, AntoineM, papidelyon, J-Marc, Gros, Jibie, Thomas_C et moi-même.
  • Contre : Bubu (même si tu ne t’es exprimé que sur un point de la proposition, je te met ici car ce point est crucial pour la faisabilité)

En ce qui me concerne, je la considère comme suffisamment soutenue pour être validée. Mais ça ne concerne que moi-même : je me sentirais bien plus confortable si le CA de l’association pouvait la tamponner de manière officielle, le sujet étant sensible :slight_smile:

#59

Je reviens un peu tard dans la discussion…
Pour moi le top des mes balises utilisées sont en vrac :

  • L# forcément…
  • L#~ pour une transition entre deux parties de topo sans en casser la mise en forme totale…
  • L#label, c’est très utile pour ajouter une longueur de transition entre deux parties de voies ex L3’ ou L3bis : marche ET aussi lorsqu’il y a des variantes de longueurs, ex L5 gauche : 7a et L5 droite variante en 6b
  • L#_ pour mettre fin à la précédente forcément…
  • R# pour numéroter les rappels et plus accessoirement pour nommer les relais dans la description des longueurs
  • De moindre importance les groupements de longueurs relatifs ou absolus.

Pour se prononcer pour la proposition 2, ça signifie quoi que tout ce qui est dans la proposition sera à nouveau fonctionnel (donc à fortiori mes top balises) ?

Question/Remarque : il arriver bien souvent que l’on trouve un || ou | | ou encore | | pour laisser une case vide, c’est très utile dans un cas où l’on ne connaisse les longueurs que de certaines longueurs ou le nombre de points que de certaines longueurs et du coup la case reste vide pour les longueur dont on ignore la caractéristique… Est-ce que le || ou | | sera bien considéré comme une case vide du coup avec la proposition 2 ?

Si ces remarques on une réponse positive, alors c’est ok pour moi ! C’est vraiment important à mes yeux que les topos redeviennent lisibles dans un futur proche (ou pas trop éloigné en tout cas ;))…

#60

Salut Thomas,

Dans tes top balises, tout ce qui est relatif aux longieurs bis (L#label, L#_, …) viendra en lot 3 car c’est le plus complexe. Les groupements de longueurs relatifs ou absolus viendront en lot 2.

Pour le séparateur, tu pourras continuer à mettre des cases vides de la même manière. Ce qui changera, c’est :

  • les deux petits points ne seront plus des séparateurs valides
  • les séparateurs consécutifs ne seront plus interprété comme un unique séparateur.

Avant :
L# : case1 | case2 || case 3 :: case 4 | | case 6 (espace dans le case 5 qui est vide) | | | | case 10 (3 cases vides avant)

Après
L# | case1 | case2 | case 3 | case 4 || case 6 (plus d'espace en case 5) ||| | case 10 (3 cases vides avant, qu'il y ait un espace ou pas)