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

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

-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org

---------------------------------------------------------------------
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]


Répondre à