Numérotation des longueurs: on fait quoi ?

#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 …

#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)

#61

Merci pour tes éclaircissement qui confirme mon avis positif sur la proposition.

Si c’est possible, je souligne que, selon moi, les L#label sont plus importants pour la lisibilité du topo et parce qu’il est plus difficile de contourner la structure que l’ensemble du lot 2 excepté R# (pour Rp2 : 15m)… En effet, L2-5 peut toujours se remplacer par L2… L3… L4… L5…

Edit en passant : Merci @CharlesB pour ces propositions pour faire avancer les choses !

#63

2 syntaxes issues de la V5 sont de nouveau fonctionnelles depuis hier soir :

Texte entre 2 longueurs.

Cette balise permet d’insérer une ligne de texte pleine largeur en conservant la largeur des colonnes après le texte.
Attention, ’ L#~ | ’ (au lieu de ’ L#~ ') fonctionne, mais pas parfaitement : affichage de --|-- en début de ligne.
Donc il vaut mieux enlever le | s’il y en a un.

Emphase de titre

Approche # 2h depuis le refuge

Permet d’ajouter du texte à droite du titre, mis en italique.
Pour l’instant ce texte est repris dans le sommaire s’il y en a un, mais le but est de ne pas le reprendre. Et la mise en forme de ce texte pourra être modifiée sans toucher à la mise en forme du titre (texte plus petit, en gris, plus éloigné du titre, à la ligne, etc).

Merci à Olivier et Charles pour ces améliorations.

1 Like
#64

Ca me semble cohérent du point de vue syntaxe d’affricher tout ce qu’il y a derrière le tilde. Si on est ok, je peux faire passer le bot pour tout nettoyer.

#65

Oui c’est logique, et conforme à ce qui a été décidé. Le petit défaut est surement du à un effet de bord, qu’il est inutile de corriger.
Il vaut mieux passer un coup de rabot :slight_smile:

#66

Merci de cette bonne nouvelle.
Je viens de vérifier sur Sapeyrlipopette, c’est très bien! Le saut à la ligne dans les commentaires aurait été utile mais ce n’est pas très grave; il conviendrait peut-être de coder le rappel en L3’ plutôt qu’en commentaire.

Merci à @charlesB et à ceux qui l’ont aidé!

#67

Mouais, je n’aime pas bien, car ça se voit moins facilement.
Avec un commentaire, on voit qu’il y a un truc bizarre qui ne se décrit pas avec le format normal d’une longueur. Et avec l’habitude, on sait que ça peut être 100m à remonter dans une pente d’herbe, un rappel, 150m de traversée sur une vire, etc. En tout cas il faut regarder de près pour ne pas avoir de mauvaise surprise : nécessité de bonnes chaussures, ou que la vire soit déneigée, ou de vérifier que la description de l’attaque de la longueur suivante est toujours bonne s’il y a de nouvelles voies qui passent pas loin, etc.
Avec L3’, en lisant trop vite on se dit qu’il y a juste 15m de 2 ou 3, et qu’on peut éventuellement enchainer avec la longueur précédente.

#68

Les apostrophes ( ’ ) n’y sont pas supportées.

Exemple (voir « Descente ») : Camptocamp.org

#69

C’est juste un chti bug temporaire, ce sera corrigé.

1 Like
#70

Super ! Merci !