Bonjour,
Le 24/08/2011 14:02, Yannick VOYEAUD a écrit :
Le 24/08/2011 07:51, Francois a écrit :
Bonjour,
L'éditeur Ancestris est sur la table de travail.
Voilà quelques éléments qu'il faut prendre en considération mais pour
lequel un débat doit s'instaurer.
Principes sur lesquels il serait basé :
- il doit respecter scrupuleusement la norme gedcom, donc pas question
de rajouter tel ou tel montage et qu'on aboutisse à dénaturer la
structure de la norme gedcom
- tous les tags de la norme doivent être présents.
- quelques tags particuliers (donc hors normes) pourront être
renseignés, je pense notamment aux tags "_WWW", "_EMAIL" voir "_LAT" et
"_LONG".
- la partie "navigateur" de l'éditeur Ancestris quand il est ouvert en
fenêtre restera. Donc un clic dans une des cases fera ouvrir la partie
"edition" de l'éditeur.
- la partie edition de l'éditeur pourrait s'ouvrir directement avec un
clic droit dans les vues table et arbre, là on ne passe pas par la
partie navigateur de l'éditeur.
Voilà pour les principes.
Ensuite, voilà quelques idées au fil de l'eau :
- est il préférable d'avoir des onglets pour cet éditeur, car il y a
beaucoup de choses à mettre, et il doit répondre à tous les tags de la
norme que ce soit pour un "individu", une "famille", un "fournisseur
d'information", une "note", un enregistrement "multimedia", un lieu "de
dépôt", une "source" d'information.
- les 7 types d'enregistrements que je viens de citer, doivent ils être
tous présents dans l'éditeur, ou au contraire l'éditeur doit il
présenter un aspect différent pour chaque type d'enregistrement. Pour
être plus explicite, un clic pour ouvrir l'éditeur présenterait dans le
premier cas toujours la même fenetre, et on irait dans l'onglet
spécifique au type d'enregistrement qu'on veut éditer. Dans le deuxième,
un clic d'édition dans une case famille de l'arbre par exemple,
ouvrirait l'éditeur mais avec les éléments spécifiques à la famille
regroupés ou non dans des onglets (vu qu'il y a beaucoup de choses à
mettre, les onglets me semblent nécessaire).
- retour du bouton "OK" pour confirmer un enregistrement?
- peut on éditer le "header" du fichier gedcom à partir de cet éditeur?
(utile notamment pour l'ordonnancement des juridictions, si on veut
régler cette question pour tout son fichier gedcom), faire une NOTE pour
décrire cette généalogie et qu'on retrouve dans le header, spécifier la
langue par défaut du gedcom (ne pas oublier qu'il n'existe pas que la
France....), stipulation d'un copyright pour les données contenus dans
ce fichier gedcom (là encore c'est dans le header), etc.
- si on part sur des onglets, faut-il mieux des onglets horizontaux
(donc dans la partie haute de l'éditeur) ou des onglets verticaux (donc
dans la partie droite de l'éditeur).
- un bouton dans la config pour que cet éditeur passe d'un éditeur
complet (donc tous les tags de la norme), à un éditeur ne présentant que
les tags les plus communs de la norme. A voir si c'est faisable, et
souhaitable.
- certains boutons dans l'éditeur ouvrirait des fenêtres qui "pop up"
pour qu'on puisse avoir toujours en vision les éléments de l'éditeur, et
en plus qu'on puisse éditer des choses plus spécifiques, je pense là aux
différentes juridictions. Un clic sur un bouton par exemple pour le lieu
de naissance d'une personne ne changerait pas l'aspect de l'éditeur,
mais ouvrirait une petite fenêtre qui viendrait se mettre au dessus de
l'éditeur pour qu'on édite les lieux plus facilement.
- etc ../..
Francois
Bonjour François et les autres,
Les informations du HEADer devrait être saisis à la création du fichier
GedCom.
En conséquence sur ce point je suggère que l'on puisse l'éditer
spécifiquement à part. En effet ces informations sont stables et peu
sujettes à modifications
de toutes façons, je crois, que la modification du header, par exemple
modifier l'ordre des juridictions, ne modifie pas le tag PLAC de l'individu
ce qui intéresse l'utilisateur c'est plutôt la façon d'afficher ses
juridictions, et à mon avis il y a beaucoup trop d'endroits pour
modifier tout ça, on s'y perd
Pour les lieux il faut distinguer deux choses:
1) le format des données
2) les formats d'affichage de ces données
Explications
1) Le format des données DOIT être FIXÉ une fois pour toutes au niveau
du logiciel donc toujours le même dans tous les fichiers. Il faut donc
imposer le format 'village, ville, INSEE, CP, département, région, pays'
qui est, amha, le minimum syndical valide partout dans le monde,
l'utilisateur pouvant créer d'autres subdivisions comme 'canton,
province (avant 1791)'. Ces ajouts venant se mettre à la fin de la
séquence précédente.
2) Ensuite nous avons l'affichage de saisie qui lui doit être paramétré
par l'utilisateur selon l'ordre qu'il veut par exemple 'village, ville,
INSEE, CP, canton, département, province, région, pays' En général je
pense que nous éclatons le PLAC en ses différentes composantes c'est
plus sûr pour la saisie et les corrections ultérieures.
Ensuite nous avons l'affichage dans le module Géo qui lui doit être
particulier de par sa fonction de base qui est vérifier les lieux dans
une base sise sur Internet. Ce module peut ajouter les fameux tags _LON
et _LAT pour ceux qui souhaitent les utiliser (Entre nous soit dit je le
conseille pour nous aider à vérifier ce que nous faisons).
Dans ce module il serait souhaitable que l'affichage des lieux soit sous
la forme suivante:
Ville
+ Lieu-dit
++ Évènements
actuellement nous avons
Ville, lieu-dit
+ Évènements
Nous avons donc plusieurs fois Ville ce qui amha n'est pas logique
Les coordonnées LONG et LAT doivent être soit saisies soit importées. Si
elles sont saisies l'import ne doit pas avoir lieu (par exemple les
villages)
Une amélioration pour les lieux serait de pouvoir comme actuellement
modifier le lieu dans tout le fichier mais en ne changeant QUE l'élément
modifié.
Si je touche le lieu-dit il me serait proposé de modifier le lieu-dit
sur toute la base lorsque ville=ville ET ancien_lieu-dit=ancien_lieu-dit
C'est ce que nous avons aujourd'huy.
À l'heure actuelle si je touche à ville la correction ne m'est proposée
que si TOUS les éléments anciens sont concordants on pourrait imaginer
que INSEE serait pris en compte et tous les villages serait modifiés
ensemble et ne pas avoir à faire la même manipulation pour chaque village.
Je conçois que pour la France c'est simple ( :-) )mais pour les autres
cas de figure c'est plus délicat
Pour l'onglet de l'éditeur proposé
Je pense qu'il faut mettre chaque évènement important dans son
sous-onglet séparé (BMS/NMD) les autres évènements ouvrant un nouveau
sous-onglet. Les classiques pouvant être à un endroit (vertical ou
horizontal) les accessoires sur l'autre.
Amitiés
---------------------------------------------------------------------
Sites Web Ancestris: http://www.ancestris.org et http://www.ancestris.com
Les archives de la liste sont disponibles sur ce site :
http://www.mail-archive.com/[email protected]
<*> Pour vous desinscrire de cette liste, envoyez un mail a :
[email protected]
<*> Pour obtenir de l'aide sur les commandes de la liste :
[email protected]
