1.0 Améliorer méthode index ou pas dans "Acquérir dans ..."

[BeCool]

XnView MP Windows
Version 1.0 32bits (Apr 28 2022)

BC.2022-10) XnViewMP Dans la commande d’acquisition en lot "Acquérir dans (TWAIN)..." (voir détails dans le post viewtopic.php?f=83&t=43530), la méthode à employer par l'utilisateur pour dire si il veut un index et de quelle taille a changé par rapport à XnView Classic.
A la place de la case "Chiffre(s)" il faut mettre un ou des "#" dans la case "Nom de fichier".

Exposé des avantages et inconvénients, puis propositions de solutions d'améliorations.

1 Inconvénients. Exposé
Case "chiffre(s)". En résumé "y'a plus, car y'a plus besoin". Ok, mais c'est quand meme moins pratique :

1.1 Un inconvénient
On ne peut plus mettre de # dans le nom de fichier. Je ne fais pas cela, mais j'ai vu que les anglophones aiment bien préfixer un numéro de séquence par ce signe # :
Exemple Scan.page#1 Scan.page#2 Invoice#2022-193 etc
et ces utilisateurs peuvent vouloir les 2: le dièse et l'index

1.2 Un inconvénient
Si on veut mettre beaucoup de chiffres, ex 5 ou 6, faut pas se tromper en comptant.

Objection : "on ne va jamais faire cent mille scans en une session !" ?
Réponse : peu probable en une session, si on commence à 1 ; mais c'est possible si on veut continuer une séquence commencée depuis longtemps, voir démarrer une numération à 7 millions.
Donc revenir à l’interface XnViewClassic pourrait etre sympa.

1.3 Question, un inconvénient
Si l'utilisateur ne met PAS de # dans "Nom de fichier", à quoi servent "Index début" et "Décrémentation" ?
De ce que je vois, on peut mettre ce qu'on veut, ca ne change pas le résultat.
Inconvénient : ca pollue l’attention de l’utilisateur.

2 Avantages. Exposé

2.1 Un avantage
Intéressant si l’utilisateur veut faire un seul scan,
et veut qu'il soit enregistré automatiquement à la fin du scan -ce que ne permet pas la commande "Acquérir"- donc puisse lancer le scan qui peut etre long et pendant ce temps faire autre chose sans s'inquiéter d'un éventuel plantage,
et veut choisir directement le nom de fichier sans que soit rajouté un suffixe, inutile dans son cas.

2.2 Un avantage
On peut mettre la spécification d'index où on veut, pas seulement à la fin = on ne spécifie plus seulement un n° en suffixe
Exemple Prefix_##-Suffix

2.3 Fonctionnalité, un inconvénient
On peut aussi mettre plusieurs spécifications d'index, et meme de longueurs différentes.
Exemple Pre#fix##-Suffix qui donnera
Pre1fix01-Suffix
Pre2fix02-Suffix
etc
Je ne vois pas l'intéret mais on peut.
Mais faut le savoir car je trouve que c'est plutot un inconvénient, car ca donne un risque d'erreur ; si l’utilisateur décide de changer de place l'index, faut pas qu'il en laisse trainer un bout ; dans mon exemple, j'ai laissé un # entre les 2 syllabes de Prefix...

3 Solutions
Là il faut choisir 2 politiques inverses :
soit on revient à l'interface Xnview Classic,
soit on garde la nouvelle interface Xnview MP.
Les 2 politiques sont possibles, dans les 2 cas j'ai des propositions de solutions pour supprimer tous les inconvénients et garder tous les avantages.

Aux lecteurs de donner leur avis, à toi Pierre de choisir -demande moi des précisions si besoin.

3.1 Tout d'abord remplacer "Nom de fichier" par "Nom de fichier(s)"
Quelque soit la solution retenue pour spécifier ou non un index (politique 1 ou 2),
ce n'est pas tout à fait le "Nom de fichier" car par définition, cette fonction est faite pour faire plusieurs scans successifs et les enregistrer au fur et à mesure, on aura donc un ou plusieurs fichiers, donc il faut mettre un "(s)" pour dire que l'utilisateur doit spécifier le nom d'un fichier (sans s) ou de tous les fichiers (avec s), meme si selon la modalité choisie plus loin ce que l’utilisateur devra remplir sera le nom du 1° fichier scanné, et meme si sera affiché l'exemple du nom du 1° fichier scanné (cf § D.3 de viewtopic.php?f=83&t=43535)
Note : par contre, meme si il y aura plusieurs fichiers donc plusieurs noms, pas de "s" à Nom, car chaque fichier n'a qu'un seul nom, on spécifie ici la règle DU nom de chacun des futurs fichiers.

3.2 Politique 1 : on revient à l'interface Xnview Classic

3.2.1 Pouvoir ne pas mettre d'index
Solution : écrire, à droite de la liste de choix, que que si la case "Chiffre(s)" contient 0, il n'y aura pas d'index
Option : si cette écriture "ne tient pas", on peut la remplacer par une petite case "?" qui affichera ce texte de mode d'emploi dans un pop up

3.2.2 Pouvoir mettre l'index n'importe où
Solution : Créer un champ "Suffixe"

Donc il faut transformer la case "Nom de fichier" en 2 cases "Préfixe de nom de fichier(s)" et "Suffixe de nom de fichier(s)" ? On peut, mais il y a mieux :

créer un bloc "Nom de fichier(s)" :
- mettre un séparateur après les blocs "Dossier" et "Sous dossier basé sur la date courante",
et un séparateur avant le bloc "Format"
- mettre une ligne avec uniquement le texte "Nom de fichier(s)", en tant que titre de ce nouveau bloc entre les 2 séparateurs
- mettre 5 lignes dans l'ordre de construction du Nom :
Préfixe
Index de début
Chiffre(s)
Décrémenter
Suffixe

Note 1 : cette solution ne prévoit qu'une zone index ? oui, ou plutot elle prévoit qu'on ne met qu'une seule fois l'index, c'est suffisant, mais que l'index sera où on veut dans le nom, au début, au milieu ou bien à la fin.
Note 2 : écrire que chacune des cases peut etre vide.
Note 3 : donc si toutes les cases sont vides, et que chiffre(s) aussi est à 0, le 1er nom serait "rien" ? Pour éviter un nom de fichier vide, possible mais pénible à utiliser, alors programmons que le 1er nom soit celui de la copie de "rien " donc _1 (puis _2 etc)

3.2.3 Conclusion
Cette politique 1 me semble facile à programmer, facile à utiliser.
Ca fait un changement pour le non utilisateur de la version Classic. mais le "#" n'est apparu que tardivement en MP (en 0.98?) donc ca ne fait pas trop d’habitudes à changer.
Et ca sera encore plus facile si est affiché l'exemple de résultat (voir § D3 de viewtopic.php?f=83&t=43535)

3.3 Politique 2 : on garde la nouvelle interface Xnview MP

3.3.1 Pouvoir mettre les 2 : des dièses et l'index
Pour continuer à pouvoir mettre un ou des caractères # ET spécifier la place de l'index et sa longueur mini dans le nom de fichier :
Solution : préfixer chacun des # que l'utilisateur veut voir insérés tels quels

Là, il y a N choix de préfixes. Mes idées : \, $, ou % (comme en unix, respectivement en shell, variable, ou format de date) etc. Mon choix : $, le dollar.

Quelque soit le préfixe choisi, il faudra écrire de doubler le préfixe pour insérer le préfixe en tant que caractère, exemple "$$" pour spécifier un simple "$".

3.3.2 Il serait bien d'aller plus loin
En profiter pour pourvoir -meme si c'est réservé pour une version ultérieure- ajouter d'autres spécifications :

- pouvoir spécifier l'insertion de tout ou partie de la date et heure de scan pour que cela soit dans le nom de fichier, indépendamment que soit utilisé ou non l'option "Sous dossier basé sur la date"
idée : en suivant la syntaxe des formats de la commande unix "date"
%Y Year = Année, 4 chiffres
%m month = mois, 2 chiffres
%d day = jour, 2 chiffres
%H Hour = Heure, 2 chiffres
%M Minute, 2 chiffres
%S Seconde, 2 chiffres
%F Full Date = raccourci identique à "%Y-%m-%d" pour toute la date complète en ISO 8601
%T full Time = raccourci pour toute la partie complète heure. Mais comme le "deux points" est interdit sous Windows, cela ne doit pas etre identique à "%H:%M:%S" ; solution : mettre des tirets, et pour différencier de la date complète, en précédant :
par le caractère "_" comme "Acquérir" qui ouvre un onglet (futur nom de fichier) Scan-AAAA-MM-JJ_hh-mm-ss.jpg
ou plutot par le caractère "T" comme Time de la norme 8601.
Ca ferait : "%_" identique à "_%H-%M-%S"
ou  : "%T" identique à "T%H-%M-%S" qui est moins ambigu, plus clair.

- pouvoir spécifier l'insertion d’éléments
$p spécifie l'insertion du dernier niveau du répertoire père = le "basename" du "Dossier"
Exemple si Dossier = "D:\data\Invoices" sera inséré "Invoices"
(si est utilisé l'option "'Sous dossier basé sur la date", on n'insère pas ce nom de sous dossier, vu que si besoin on peut utiliser %F)

- pouvoir insérer un indicateur donnant la valeur de chaque mode utilisé :

$M "M" si multipages utilisé, rien sinon

$R "O" comme Odd, si Pages paires
"E" comme Even, si Pages impaires
"B" comme Both, si Pages paires et impaires
rien si introducteur RV non présent ou non utilisé
A fusionner avec le traitement de mon post viewtopic.php?f=83&t=43534 où, plutot que la parité de la page, paire et ou impaire, je mettrais le coté : Recto et ou Verso, il faut donc adapter les abréviations : respectivement "F" comme Front et "V" comme Verso ? en tout cas pas B comme Back, utilisé pour Both ; pas R comme Reverse, ambigu avec Recto.

- et d'autres variables si besoin

- avec le #, ca fait 3 caractères utilisés comme début de spécification. Il faut donc écrire quelque chose comme :
$$ insertion d'un caractère "$"
$% insertion d'un caractère "%"
$# insertion d'un caractère "#"
Note : à la place de "un", comme dans la doc/pop up on peut ne pas avoir le souligné ou qu'il sera peu lisible, on peut écrire "un seul" ; évite d'écrire que : "Si on veut plusieurs caractères d’utilisation spéciale, il faut répéter ce qu'écrit la doc", évite de ne donner qu'un exemple sur un seul caractère spécial : "Donc il faut par exemple taper $#$# pour insérer 2 # etc"

3.3.3 Conclusion
Cette politique 2 est moins facile pour l’utilisateur, mais -potentiellement- plus riche. A ne retenir que si on veut utiliser ce potentiel.

3.4 Si l’utilisateur ne demande pas d'index, griser "Index début" et "Décrémentation"
Quelque soit la solution retenue pour spécifier ou non un index (politique 1 ou bien 2) = si l’utilisateur met "Chiffre(s)" à 0 ou bien ne met pas de #, c'est qu'il ne veut pas d'index, il faut donc griser "Index début" et "Décrémentation" qui sont sans objet.

Politique 1 : il faut les griser dès que "Chiffre(s)" est passé à 0, les dégriser dès que "Chiffre(s)" à passé à autre chose que 0.

Politique 2 : Mon avis : il faut les griser au départ = quand le champ "Nom de fichier(s)" est vide, et :

a) au mieux, les dégriser dès que l’utilisateur a tapé un premier #, les regriser dès qu'il efface le dernier #.
(des logiciels font cela ; dont FastStone Image Viewer (FSIV) dans sa commande F4 "renommer un groupe", mode "utiliser modèles de fichiers")

b) au pire, les dé/griser après que l’utilisateur aura terminé le champ "Nom de fichier(s)", en ayant fait un Tab ou cliqué ailleurs.
Ca peut etre plus facile à programmer mais c'est moins pratique, des utilisateurs vont faire des rapports d'anomalies, du genre : "Index début reste grisé" pour tous ceux qui n'ont pas de changement à faire dans les autres champs. Si la solution a) n'est pas retenue, idée : faire une case à cocher "avec index", mais on se rapproche du mode Classic...
Mais ce b) ne devrait pas se poser car à mon sens l'affichage l'exemple de résultat (voir § D3 de viewtopic.php?f=83&t=43535) se doit d'etre mis à jour au fur à mesure, dès que l'utilisateur fait une modification dans un quelconque des champs : insertion/effacement d'un caractère, coche/décoche d'une case, clic incrément + ou -.
Donc si la programmation sait suivre pour l'exemple, elle saura suivre pour les grisés/dégrisés.
Occasion de féliciter Pierre pour son travail !