Skip to content
Doug Blank edited this page Sep 22, 2026 · 1 revision

🌐 English · Deutsch

FAQ

En quoi gramps-connect-desktop diffère-t-il du déploiement basé sur serveur ?

gramps-connect-desktop est la version autonome (voir Installation). Un seul fichier regroupe le frontend de app/ et le backend de gramps-web-api avec SQLite, s'exécute entièrement sur votre propre machine, et n'écoute que sur 127.0.0.1 — rien n'est accessible via un réseau, et il a toujours exactement un utilisateur fixé en dur (admin/admin). C'est fait pour essayer Gramps Connect sur votre propre machine, pas pour partager un arbre avec quelqu'un d'autre.

deploy/ est la véritable forme multi-utilisateur : un app/ conteneurisé + backend gramps-web-api adossé à un véritable Postgres, devant lequel se trouve Caddy pour le TLS, destiné à être réellement hébergé quelque part — de vrais secrets, un vrai domaine/certificat, et plusieurs utilisateurs ayant chacun leur propre identifiant. C'est aussi le seul moyen de voir la collaboration en direct en action — la version autonome est conçue pour un seul utilisateur, il n'y a donc personne d'autre dont regarder apparaître les modifications.

Comment gramps-connect-desktop se compare-t-il à Gramps Desktop ?

Plus proche que ne le suggère peut-être « déploiement basé sur serveur » ci-dessus — les deux sont des applications mono-utilisateur, strictement locales, construites sur la même base de données Gramps sous-jacente. Aujourd'hui, Desktop est loin devant en fonctionnalités : des décennies d'outils natifs, de gramplets, et de rapports que la couche REST de gramps-web-api ne couvre pas (encore), ce n'est donc pas un remplacement direct. Mais une interface plus rapide, basée sur le navigateur, sur les mêmes données, est un vrai candidat pour finalement rivaliser avec Desktop pour un usage quotidien.

Mes données ou tout ce que je fais dans gramps-connect-desktop sont-elles envoyées quelque part ?

Non. Il n'écoute que sur 127.0.0.1, la télémétrie est désactivée, et tout ce qu'il stocke réside dans ~/.gramps-connect-desktop sur votre propre machine. La seule exception, à activation volontaire, est l'e-mail sortant (réinitialisation de mot de passe, etc.) — voir Installation#configuration — qui est désactivé sauf à le configurer délibérément.

Puis-je importer mon véritable arbre familial dans gramps-connect-desktop ?

Oui — Arbres généalogiques → Importer… accepte un fichier Gramps XML (.gramps) ou GEDCOM (.ged), comme le vrai déploiement. Simplement ne pas le traiter comme votre seule copie — garder une sauvegarde dans tous les cas, comme il se doit pour tout outil encore en développement actif.

Mettre à jour gramps-connect-desktop efface-t-il mes données ?

Non — ~/.gramps-connect-desktop est séparé du binaire de l'application, installer une version plus récente réutilise donc ce qui est déjà là. Supprimer ce dossier vous-même pour repartir de zéro.

gramps-web (l'autre frontend web de Gramps) peut-il tourner contre le même backend ?

Oui, pour le déploiement serveur. Le backend dans Déploiement est une instance gramps-web-api ordinaire et non modifiée, gramps-project/gramps-web peut donc aussi y pointer — mêmes données, mêmes arbres/utilisateurs, juste une interface différente sur un port différent. Voir Déploiement#running-gramps-web-alongside-gramps-connect pour savoir comment configurer cela.

Quels formats de fichiers généalogiques Gramps Connect prend-il en charge ?

Gramps XML (.gramps) et GEDCOM (.ged) — les mêmes formats qu'utilisent Gramps Desktop et gramps-web, un arbre peut donc circuler librement entre les trois.

Puis-je avoir Gramps Connect ouvert dans plus d'un onglet de navigateur à la fois ?

Oui — chaque onglet est un client indépendant du même backend gramps-web-api (voir Architecture) ; les onglets ne se parlent jamais entre eux et ne stockent pas non plus eux-mêmes vos données d'arbre. Travailler sur des personnes, lieux, ou événements différents dans des onglets différents est parfaitement sûr et ajoute une charge négligeable — la seule activité en arrière-plan de chaque onglet est la petite requête de la synchronisation en direct toutes les quelques secondes (voir Architecture#live-sync).

Deux choses rendent cela vraiment sûr, pas seulement « généralement correct » :

  • Le stockage est délimité de sorte que les onglets ne puissent pas interférer. La connexion réside dans un sessionStorage propre à chaque onglet, chaque onglet démarre donc sa propre session (voir Sous le capot). La seule chose que les onglets partagent réellement, ce sont de petites préférences d'interface dans localStorage (largeurs de colonnes, dernier nœud d'arbre déplié, …) — jamais des données généalogiques.
  • Le seul vrai risque — modifier la même fiche dans deux onglets — est intercepté avant de pouvoir causer des dégâts. Enregistrer une Personne/un Événement/un Lieu/etc. est une écriture de l'objet entier ; avant qu'elle ne parte, l'application récupère à nouveau cette fiche et la compare à ce qu'il y avait quand elle a été ouverte pour modification (saveAll() de app/src/store/draftStack.ts). Si elle a changé ailleurs entre-temps — un autre onglet, ou un autre utilisateur sur un serveur partagé — l'enregistrement est bloqué avec une erreur invitant à rouvrir la fiche, plutôt que d'écraser silencieusement qui a enregistré en premier.

La base de données SQLite de la version pour ordinateur est-elle sûre à utiliser depuis plusieurs onglets ?

Oui. Même si gramps-connect-desktop stocke l'arbre dans un seul fichier SQLite, chaque onglet de navigateur parle à la même copie locale de gramps-web-api, et ce serveur est délibérément configuré pour traiter une seule requête à la fois (threaded=False dans standalone/launcher.py), plutôt que plusieurs à la fois. Ce n'est pas un goulot d'étranglement accidentel — il est là parce que le backend SQLite de Gramps peut verrouiller définitivement la base de données si deux requêtes atteignent close() en même temps (confirmé en direct : un véritable import d'environ 10 000 objets suivi immédiatement d'un rechargement de page l'a reproduit, et l'arbre ne s'en est jamais remis sans tuer le processus). Sérialiser chaque requête à travers un seul thread contourne complètement cette course, le fichier n'est donc jamais touché par deux requêtes à la fois, peu importe le nombre d'onglets ouverts.

Où puis-je poser des questions ou signaler un problème ?

Les discussions ont lieu sur le forum Discourse de Gramps ; les issues et pull requests contre le dépôt gramps-connect sont les bienvenues. Voir Développement.

Clone this wiki locally