Salut tout le monde,
Salut Gontran :-)
Gontran a écrit :
>
> Dans cet exemple, la fonction print_msg() est appelée avant print_status(),
> et
> malgré ça, le "OK" est affiché sur la ligne affichée par print_step(). Or, si
> un nombre important d'appels à print_msg() fait que la ligne affichée par
> print_step() « sort » de l'écran, l'état ne pourra plus être affiché sur la
> ligne d'étape, et donc l'utilisateur n'aura aucune indication sur le succès
> ou l'échec de cette étape.
>
> Dans un précédent message, j'ai proposé d'afficher l'état après les éventuels
> messages comme ceci :
>
> $ Ncooker -v MAIN search xine
>
> Searching packages whose name contains "xine" ...
> libxine-1.0.1
> xine-ui-0.99.3
> \.................................................................. [ OK ]
>
> $ Ncooker -v INFO search xine
>
> Searching packages whose name contains "xine" ...
> Searching in "Nasgaïa CD" provider ...
> libxine1-1.0.1
> xine-ui-0.99.3
> \............................................................. [ OK ]
> Searching in "Nasgaïa contrib" provider ...................... [ FAILED ]
>
> Si un nombre important de messages sont affichés par print_msg(), l'état
> serait quand même affiché.
>
> Cette solution convient-elle ?
> Si oui, il faudrait que la fonction print_status() sache à l'aide d'une
> variable globale quelle fonction print_step() ou print_msg() a affiché le
> dernier message. Si c'est la première, print_status() affiche l'état au bout
> de ce message comme c'est le cas actuellement. Si c'est la deuxième, elle
> affiche "\.... [ <état> ]", avec l'indentation générale en cours, sur une
> nouvelle ligne.
Je suis entrain de me dire que le point soulevé par ton exemple
peut-être résolu d'une autre manière sans avoir à faire des
\............................................................. [ OK ]
que je ne trouve pas super beau (mais j'ai rien de mieux ;-) )
Typiquement :
Quand on cherche un paquet dès qu'on en a trouvé au moins un alors on
peut considéré le status de l'étape comme 'OK' et faire un print_status
'OK' dès qu'on trouve un paquet.
Ce qui nous donnerai l'affichage suivant :
Searching packages whose name contains "xine" ...
Searching in "Nasgaïa CD" provider ...................... [OK]
libxine1-1.0.1
xine-ui-0.99.3
Searching in "Nasgaïa contrib" provider ................. [FAILED]
Car le print_status aura été fait avant les print_msg successifs
Etant donné que le print_status décrémentera le level, il faut avoir une
fonctionnalité du type INDENT ou NO_INDENT selon qu'on décide si par
défaut c'est INDENT ou NO_INDENT. Je pencherai, comme toi, pour INDENT
par défaut, et garder NO_INDENT : ça coute rien et ça peut être utile.
De plus le coup du ALWAYS me convient parfaitement pour palier au
problème associé que tu as très justement soulevé. Je pense même que par
défaut un message de print_msg doit être ALWAYS affiché :-). On aurait
donc NOALWAYS comme option (ou autre nom qui convient).
On aurait donc :
print_msg "toto" (automatiquement indenté et toujours affiché)
print_msg NO_INDENT "toto" (même niveaux que l'étape précédente et
toujours affiché)
print_msg NOALWAYS "toto" (automatiquement indenté et affiché selon la
verbosité définie par l'utilisateur)
print_msg NOALWAYS NO_INDENT (même niveaux que l'étape précédente et
affiché selon la verbosité définie par l'utilisateur)
- Cette solution suppose que le developpeur est discipliné et ne
laissera pas de print_step ouvert avant de faire un print_msg.
- Cette solution suppose qu'il n'y ait pas de cas où il faille faire un
print_msg avant de faire un print_status : en vois-tu ?
Tu en penses quoi ?
>
> Oui, c'est un problème auquel j'ai pensé aussi. Une manière de « retarder »
> le
> phénomène serait d'utiliser une indentation plus petite. Actuellement, elle
> est de 4 caractères espace, on pourrait la descendre à 3 caractères. Avec 2
> caractères, la lisibilité risque aussi d'en prendre un coup :-) Perso, je ne
> pense pas qu'il faut mettre des garde-fous partout. Si on ne trouve pas de
> solution idéale, ce sera aux développeurs de faire attention à ne pas aller
> trop loin dans le niveau de détails.
>
Comme tu le dis c'est n'est que retarder le problème. Certes, je suis
d'accord qu'on ne pourra pas mettre des garde-fous partout, mais je
pense que ma crainte est fondée : pour l'instant on développe des
commandes/modules relativement bas niveau. On arrive déjà à du niveau
FULL. Imagines une commande haut niveau comme Ncooker update world. La
tu peux être sur qu'on va sortir du terminal.
Ensuite le fait de diminuer le nombre des espaces pour l'indentation
diminuera la clareté des messages comme tu le dis très bien.
La solution :
blablabla............
> blebleble............
> bliblibli............
> blobloblo............
> (+1) blublublu............
> (+2) blyblybly............
me plait le plus pour l'instant.
Changes-tu ton opinion sur ce problème ou souhaites tu toujours le
laisser de côté pour l'instant ?
++
Chicha (dispo sur irc ce soir)
