avis sur Gramps, qualités / défauts

[forhanp]

Bonjour,

Je pense malgré tout que l'on s'éloigne un peu du sujet dans la mesure ou ce genre de considérations sont plus destinées à des informaticiens qu'à l'utilisateur "moyen" d'un logiciel de généalogie.
Je ne vois pas la qualité de code comme fonctionnalité mise en avant pour l'adhésion à un logiciel.

Cordialement,

[lucsecouard]

@bcallens

Bonjour,

Je réponds à vos remarques, tout à fait pertinentes, avec quelque retard.

Mais les informations généalogiques sont toujours les mêmes quel que soit le logiciel utilisé : des noms, des dates, des lieux, des événements, des sources etc.

Oui, mais la manière de les représenter peut varier fortement. Gramps a une gestion très sophistiquée des lieux. Il n’est pas du tout évident que le Gedcom X soit aussi riche et s’il ne l’est pas, il faudra définir les règles pour faire tenir la sémantique de Gramps dans ce qu’offre le Gedcom X.

De même, pour les dates, si, par extraordinaire, Gramps sait gérer un calendrier que le Gedcom X ne connaît pas, il faudra faire une conversion, par exemple dans le calendrier grégorien. Et, de toute façon, il serait bien étonnant que le format des dates soit exactement identique, donc outre une opération de réorganisation il faudra aussi réaliser du formatage, en prenant en compte tous les calendriers de Gramps dans un sens et du Gedcom X dans l’autre.

En complément, on doit prendre en compte tous les objets, attributs, valeurs prédéfinis qui pourront différer, avec j’imagine de subtils distinguos comme celui entre baptism et christening du Gedcom.

Le vrai travail, comme je l’ai dit, n’est pas de réaliser le convertisseur, mais de spécifier les règles de conversion. Tout ce qui est commun sera raisonnablement facile à traiter. Tout ce qui est spécifique, notamment la gestion des lieux et des noms imposera de réfléchir aux règles de correspondance.

Ceci étant, je n’ai pas regardé le modèle Gedcom X en détail et la conversion est peut-être très facile. Mais comme on dit, le diable est souvent dans les détails.

[bcallens]

Bonjour,

J'entends bien vos arguments mais je pense qu'il faut considérer deux choses.

La première est qu'une norme peut évoluer. Le modèle de Gramps évolue d'ailleurs de temps en temps.

La seconde est que les Mormons ont une vision assez ouverte de la généalogie et se sont donnés comme ambition de traiter les généalogies du monde entier et pas seulement les leurs...

Je n'ai pas regardé dans le détail la spécification mais j'imagine que de ce fait ses concepteurs ont dû partir du principe qu'il fallait prendre en considéreration tous les cas de figure possibles.

Cordialement

[lucsecouard]

Bonjour.

Ayant dû m’absenter, je n’ai pu intervenir dans ces échanges fort intéressants. Je me permets d’apporter mon point de vue sur les formats généalogiques.

Il existe, à mon avis, deux types de formats : les formats d’échange et les formats que j’appellerai « formats de sauvegarde », puisque c’est leur objet premier, mais dont l’utilité va au delà. Le format de sauvegarde de Gramps, c’est Gramps XML. D’autres logiciels ont leur format de sauvegarde comme Geneweb.

Le Gedcom a été conçu dès l’origine comme format d’échange. Comme à l’époque on n’utilisait pas de fichiers électroniques, il a été conçu pour être enregistré sur des supports comme les cartes perforées, ce qui explique sa syntaxe bizarre qui pose d’ailleurs quelques problèmes à certains logiciels.

On peut bien sûr utiliser le modèle sous-jacent du Gedcom comme modèle pour sa base de données ou, même, se passer complètement de base de données et travailler directement sur un fichier Gedcom (cf. lifelines). Mais, de manière générale, les logiciels de généalogie ont leur propre modèle de données qui ne recouvre pas complètement le Gedcom (avec des possibilités en plus ou en moins).

Gramps XML, de son côté, est d’abord le format qui est utilisé pour sérialiser les données de la base. Comme je l’ai écrit, mais sans insister suffisamment, ce format permet de sauvegarder les données et de les restaurer à l’identique. C’est une propriété remarquable parce que, si vous attendez logiquement de votre sauvegarde qu’elle vous permette de récupérer vos données, rien n’oblige le logiciel à restaurer à l’identique les données techniques qui les accompagnent, notamment les divers identifiants des objets. Ce n’est pas une propriété si évidente et si commune, ce pourquoi j’avais voulu mettre l’accent dessus.

Pour revenir au sujet, il se trouve que Gramps XML peut aussi être utilisé comme format d’échange entre utilisateurs de Gramps. C’est un bien meilleur choix que le Gedcom car on sait que l’intégralité des données que l’on transmet seront récupérées par le destinataire. En fait, le problème du Gedcom n’est pas tant qu’il soit limité. C’est surtout que, sauf à connaître le format et ses subtilités, on n’est pas absolument certain de ce qui va être transmis. Et, en plus, il faut faire confiance à la procédure d’exportation d’un côté et à la procédure d’importation de l’autre.

Bien sûr, quand on exporte vers ou importe depuis un autre logiciel que Gramps, on n’a pas le choix. Et pour des échanges simples, cela ne pose pas de problèmes je suppose.

En pratique, il n’existe pas d’autre format d’échange que le Gedcom et le Gedcom X n’arrive même pas à être simplement reconnu. Pourquoi cette frilosité dans le monde de la généalogie ? Je ne sais pas, mais cela me semble tout de même un cas assez unique. Le Gedcom apparaît réellement comme une curiosité, un vestige des temps héroïques. Et si encore les logiciels l’interprétaient tous de la même manière et n’ajoutaient pas leur propres extensions !

Quant aux avantages d’un format de sauvegarde, de préférence textuel, ils sont multiples et ont déjà été cités par ailleurs. Je les résume à ma manière :
– assurance de disposer de l’intégralité de ses données sous une forme structurée et documentée et, si la forme est textuelle, lisible sans outillage particulier ;
– possibilité de réaliser une véritable migration de données en cas de changement volontaire ou forcé de logiciel de généalogie ;
– possibilité de réaliser des traitements divers sur la forme sérialisée, donc à l’extérieur de Gramps (statistiques, conversions, contrôles de cohérence spécifiques, etc.).

Alors, certes, ces points n’intéressent pas forcément les généalogistes non programmeurs qui préféreront un outil plus agréable à prendre en main et utiliser, à défaut d’être plus puissant. Mais, le deuxième point reste valide dans tous les cas et trouver quelqu’un capable d’effectuer une migration n’est pas insurmontable si le problème devait se poser. Car, sinon, la migration, évidemment forcée dans ce cas, se réduira à un export en Gedcom et une importation de ce qui sera resté de la généalogie dans le nouveau logiciel. On aura perdu beaucoup de choses et il y aura probablement beaucoup d’erreurs. Ce sont, selon la taille de la généalogie, des mois ou des années de travail qui seront perdues.

Cordialement.

[glopglop]

Bonjour

Je voulais illuster vos dire par un exemple dans la vraie vie.

quand TMG a mis la clé sous la porte les utilisateurs ont eu trois choix.

- Exporter en gedcom
- migrer vers gramps avec le reprise integrale des données avec l'outil tmgtogramps
- faire la meme chose pour migrer vers Yggdrasil.

Le premier choix impliquait une perte importante de données
et concernant le troisieme choix bah yggdrasil ce n'est pas vraiment un logiciel de genealogie. En particulier il ne supporte pas l'export gedcom

TMG etant un logiciel proprietaire il etait impossible pour ses utilisateurs de continuer son developpement et de corriger des bugs

[dhavrais]

Bonjour à tous


je lis actuellement tous les avis et toutes remarques sur Gramps. C’est très intéressant.
Je suis un peu lucsecouard, je suis sous Windows 10 et non sur mac avec Heredis 19 mais utilise Libreoffice - Gimp - Easyphp - Thunderbird - Firefox - Filezila – Je souhaite au final "glisser" de Heredis 19 vers Gramps puis de windows 10 vers Linux.

Le côté un peu « Brut » de gramps ne me rebute. Tout avec d’accord avec la citation de Glopglop « l’être et le paraître ... » moi j’avais la version nénuphar ... « tout en surface tout dans le paraître mais rien en profondeur !!. »

Heredis 19 sauvegarde en SQL il est donc possible de parcourir la base. J’ai débuté la programmation avec un amstrad 2168 et locomotive Basic puis Visual- Basic et Delphi. maintenantj’utilise plus HTML-CSS et Mysql-PHP pour la création de notre « excellent » site http://desarmementshavrais.free.fr/accueil.php

Comme il est dit dans les échanges le vrai problème c’est e fichier gedcom qui n’a pas évolué.

Je souhaite créer sous Heredis un petit fichier de 8 personnes enfants parents et grands-parents en y insérant le maximum de choses les 3 actes naissance mariage décès mais aussi des contrats de mariage, des tutelles, inventaire après décès. Et voir comment se comporte le fichier Gedcom. Et pourquoi pas écrire un greffon qui corrige tout ça. j’ai commencé à me documenter sur le Python. Une solution peut-être mettre les infos dans « notes » des évènements (désolé glopglop) mais j’ai du mal à imaginer une généalogie qui se limite qu’aux 3 dates importantes de la vie BMS.
Bonne journée à vous tous.

[patricelegoux]

Bonjour dhavrais,

Ceci peut peut-être aider à la migration:

https://www.gramps-project.org/wiki/index.php/Import_from_another_genealogy_program#Heredis

Patrice

[glopglop]

Bonjour

le passage par les "notes" est en fait un aveu de faiblesse.
on fait comme cela parce que l'on n'a pas d'autres choix possible.

l'ideal serait d ecrire un her2gramps comme un tmg2gramps a été ecris
mais ce n'est pas un sinécure.

On se rend bien compte que le changement de logiciels est vraiment tres tres compliqué et c'est
mission accomplie par les editeurs.

P.S.
par curiosite jaimerais bien voir un dump d'une base exporte par heredis.

[lucsecouard]

@dhavrais

Bonjour,

À ma connaissance, Heredis pour Windows utilise une base SQLite. Cela signifie que la phase de rétro-analyse est un peu simplifiée par rapport au travail que j’avais dû faire sur Mac : au lieu d’essayer de comprendre comment sont stockées les données dans un fichier binaire, il suffit de comprendre comment est constitué le modèle relationnel utilisé par Heredis.

Cela ne signifie pas que ce soit un travail simple. Si identifier les tables est certainement assez évident, il faut repérer l'emplacement de tous les attributs, leur type et leur format éventuel.

J’avais pour ma part procédé ainsi :
– construire une vue relativement complète du modèle utilisé par Heredis (j’ai ignoré les éléments que je n’utilisais pas) ; pour cela, j’avais construit de nombreux petits tests élémentaires afin de repérer où étaient stockés les attributs ;
– établir les règles de correspondance avec le modèle de Gramps ; c'est l’étape la plus importante durant laquelle doivent être prises des décisions structurantes ;
– écrire les modules chargeant les données d’un fichier d’Heredis 3 (décodage depuis le fichier binaire) et en construisant une représentation en mémoire ;
– écrire le module produisant le fichier XML de Gramps (et contenant donc la logique de correspondance entre les modèles).

La programmation n’a pas été compliquée. Ce qui a été compliqué, c’est la rétro-analyse et surtout la définition des règles de correspondance car il y a beaucoup de détails à prendre en compte.

Mon script n’était donc pas complet, se contenant de traiter les éléments que j’utilisais (ce qui devait tout de même représenter au moins 95% des fonctions d’Heredis 3). Il incorporait aussi le traitement de conventions personnelles diverses : par exemple, puisque qu’Heredis 3 ne permettait d’associer plusieurs notes à un objet, de découper une note unique contenant de multiples informations en plusieurs notes contenant une seule information.

Je considère la réalisation d’un script similaire pour la version d’Heredis pour Windows, comme tout à fait réalisable, mais il faut procéder méthodiquement. Il ne sert à rien de programmer quoi que ce soit tant que vous n’avez pas une connaissance suffisante du modèle de données d’Heredis.

Je doute que mon script puisse vous être utile car il est assez fortement lié au modèle d’Heredis 3 tel que je l’ai reconstruit. Il pourrait éventuellement être intéressant pour récupérer la logique de production du fichier XML de Gramps, même si, depuis 2011, le modèle de données de Gramps a, lui aussi, fortement évolué. À l’époque, la gestion des lieux était beaucoup plus simple (non hiérarchique) et il n’existait pas de citations, seulement des sources (comme Heredis 3 ne gérait pas non plus les citations, cela tombait bien).

Par ailleurs, j’imagine que la version actuelle d’Heredis pour Windows doit être bien plus riche que la version 3 d’Heredis pour Mac. Même si je ne doute pas de la capacité de Gramps de représenter la quasi totalité des informations gérées par Heredis, il faudra définir les règles de correspondance.

Ceci étant, si cela vous semble utile, je pourrai vous transmettre mon script (environ 4000 lignes de Python). C’est relativement lisible et c’est correctement structuré (huit ans après, j’arrive à m’y retrouver ). Comme je l’ai dit, ce n’est pas de la programmation compliquée, c’est de la programmation avec plein de petits détails pour assurer la correspondance des modèles. Mon script peut alors donner une indication sur la manière de procéder. À vous de voir.

Si vous le souhaitez, je suis aussi prêt à discuter avec vous plus en détail sur ce sujet.

Cordialement.

[romjerome]

– écrire le module produisant le fichier XML de Gramps (et contenant donc la logique de correspondance entre les modèles).

Si besoin, mon dépôt 'fourre-tout' me permettait de jouer avec les versions XML de Gramps. Le 'gramplet lxml' peut par exemple servir d'exemple pour une interface de transformation de (ou vers) un fichier XML de Gramps valide, ou tout simplement pour la création d'un fichier XML pour Gramps.

Un simple fichier texte résume le modèle actuel de Gramps (format XML). Par ailleurs, les principaux schémas 'Gramps XML' sont également disponibles dans le dépôt (ceci va plus loin que les simples fichiers DTD et RNG présents dans les sources !).

[barrail]

Je retombe sur ce fil trois ans après.
J'ai depuis abandonné définitivement Gramps. Bien sûr, il a de nombreuses qualités, mais aussi comme souvent énumérés dans ce fil, beaucoup de défauts.
Cependant, sachant que chacun cherche des qualités potentielles souvent différentes dans un logiciel de généalogie, il n'est pas vraiment possible de faire un résumé ou de conclure.
Sur l'essentiel, entrent en jeu le plaisir de se servir d'un soft agréable et stimulant, d'évoluer dans une interface efficace et claire, mais aussi l'export, la compatibilité, les différents aspects techniques, sa puissance de travail.

Quelques logiciels arrivent plus ou moins à allier les deux, mais Gramps, à mon sens, ne fait pas partie de ceux-là.

[glopglop]

Bonjour

Quel dommage de ne plus vous compter dans nos rangs.
Il est vrai que GRAMPS nécéssite un investissement personnel non négligeable pour pouvoir en apprecier toute sa puissance.
Tout le monde n'est pas prêt a faire cet investissement et alors GRAMPS n'est pas alors le logiciel idéal.

Par pure curiosité peut on savoir si vous avez déjà jeter votre dévolu sur un autre logiciel?

[barrail]

Je me suis beaucoup, beaucoup plongé dans Gramps, et il y avait certainement un investissement personnel de ma part, je pense.
Mais, en ce qui me concerne, les défauts de cet outil l'ont emporté sur les qualités.
Par contre, bien évidemment,si de nombreuses personnes, dont vous, sont très satisfaites de ce logiciel, alors c'est très bien et montre son utilité (sans compter la démarche même des concepteurs qui proposent un soft gratuit, merci à eux).

Pour le reste, je suis passé à du visuel direct (voir Forum Autres logiciels).

[phcook]

Hello

Et quel serait selon vous LE gros défaut de Gramps?

philippe

[patricelegoux]

Bonjour,

L'exhumation de ce fil m'a donné l'occasion de le relire entièrement.

Si je devais le résumer en quelques points ce seraient ceux-ci:
- son interface: pour beaucoup
- ses greffons: pour certains, pour d'autres
- son côté geek: pour certains, pour d'autres
- ses possibilités: pour beaucoup

Concernant le premier point, des évolutions sont en cours, et je ne crois pas avoir vu en parler sur ce forum. Je pense en particulier à Gramps Web qui interface Gramps entièrement différemment.

Web; donc en lecture des données de gramps mais aussi en écriture car interfacé en direct avec Gramps et sa base de données. Le lien que j'ai indiqué précédemment pointe sur une base Gramps de test que vous pouvez visualiser mais aussi modifier, tout ça via cette URL !

Le côté geek ne va par contre pas s'arranger car l'installation de cette interface - qui n'en est qu'à ses débuts - risque pour l'instant d'être plutôt compliquée pour le commun des mortels dans son état actuel de développement (mais je suppose que ça pourra s'arranger plus tard, elle est déjà un peu plus simple qu'à ses débuts).

Un autre avantage de cette interface (d'un composant entre elle et Gramps en fait, l'API Gramps) permet de travailler à plusieurs sur une même base, sujet qui n'est ni mentionné en positif ni en négatif dans ce fil mais qu'on voit parfois être demandé par les utilisateurs de gramps. S'il existe des mécanismes dans Gramps pour réconcilier des xml provenant d'un tiers ils sont (beaucoup) moins simple que d'utiliser la même base à plusieurs mains.

Voilà donc une réponse à un des sujets principaux évoqués dans ce vieux fil. Il y en a d'autres à propos d'autres sujets que j'ai vus en le relisant mais moins prégnant que celui de l'IHM.

Pour en savoir plus:
- Gramps Web API
- Gramps (.js) Web Frontend

N.B: toutes les fonctions de Gramps ne se trouvent pas encore dans Gramps Web qui est encore en cours de développement mais les petticoat fonctions sont déjà présentes

Alors ? Son interface ?