🌐 Also available in: Deutsch · Español · Français · Nederlands · 简体中文

FAQ

How does gramps-connect-desktop differ from the server-based deployment?

gramps-connect-desktop is the standalone build (see Installing). One file bundles app/'s frontend and gramps-web-api's backend together with SQLite, runs entirely on your own machine, and only listens on 127.0.0.1 — nothing about it is reachable over a network, and it always has exactly one hardcoded user (admin/admin). It's for trying Gramps Connect on your own machine, not for sharing a tree with anyone else.

deploy/ is the real multi-user shape: a containerized app/ + gramps-web-api backed by real Postgres, fronted by Caddy for TLS, meant to actually be hosted somewhere — real secrets, a real domain/certificate, and multiple users each with their own login. It's also the only way to see live collaboration in action — the standalone build is single-user by design, so there's no one else's edits to watch appear.

How does gramps-connect-desktop compare to Gramps Desktop?

Closer than "server-based deployment" above might suggest — both are single-user, local-only apps built on the same underlying Gramps database. Today, Desktop is far ahead on functionality: decades of native tools, gramplets, and reports that gramps-web-api's REST layer doesn't (yet) cover, so this isn't a drop-in replacement. But a faster, browser-based UI over the same data is a real candidate to eventually rival Desktop for day-to-day use.

Will my data or anything I do in gramps-connect-desktop get sent anywhere?

No. It only listens on 127.0.0.1, telemetry is disabled, and everything it stores lives in ~/.gramps-connect-desktop on your own machine. The one opt-in exception is outbound e-mail (password reset, etc.) — see Installing#configuration — which is off unless you deliberately set it up.

Can I import my real family tree into gramps-connect-desktop?

Yes — Family Trees → Import... takes a Gramps XML (.gramps) or GEDCOM (.ged) file, same as the real deployment. Its preview step lists what the file contains and, if the importer had trouble with any of it (most often GEDCOM lines it doesn't understand), shows that report — with the offending file line numbers and a Copy button — before you commit to importing. If the real import reports problems too, the dialog shows them before reloading instead of reloading straight away. (The report needs a gramps-web-api server from v3.23.0 on; older servers just skip it.) Just don't treat it as your only copy — keep a backup regardless, the way you should for any tool still under active development.

Does upgrading gramps-connect-desktop wipe my data?

No — ~/.gramps-connect-desktop is separate from the app binary, so installing a newer version reuses whatever's already there. Delete that folder yourself if you want a clean slate.

Can gramps-web (the other Gramps web frontend) run against the same backend?

Yes, for the server deployment. The backend in Deploying is a plain, unmodified gramps-web-api instance, so gramps-project/gramps-web can point at it too — same data, same trees/users, just a different UI on a different port. See Deploying#running-gramps-web-alongside-gramps-connect for how to wire that up.

What genealogy file formats does Gramps Connect support?

Gramps XML (.gramps) and GEDCOM (.ged) — the same formats Gramps Desktop and gramps-web use, so a tree can move freely between all three.

Can I have Gramps Connect open in more than one browser tab at once?

Yes — every tab is an independent client of the same gramps-web-api backend (see Architecture); tabs never talk to each other or store your tree data themselves. Working on different people, places, or events in different tabs is completely safe and adds negligible load — each tab's only background activity is live sync's small poll every few seconds (see Architecture#live-sync).

Two things make this safe rather than just "usually fine":

• Storage is scoped so tabs can't interfere. Your login lives in per-tab sessionStorage, so each tab starts its own session (see Under-the-Hood). The only thing tabs do share is small localStorage UI preferences (column widths, last-expanded tree node, ...) — never genealogy data.
• The one real risk — editing the same record in two tabs — is caught before it can do damage. Saving a Person/Event/Place/etc. is a full-object write; before it goes out, the app re-fetches that record and compares it to what was there when you opened it for editing (app/src/store/draftStack.ts's saveAll()). If it changed elsewhere in the meantime — another tab, or another user on a shared server — the save is blocked with an error telling you to reopen it, instead of silently overwriting whoever saved first.

Is the desktop build's SQLite database safe to use from multiple tabs?

Yes. Even though gramps-connect-desktop stores your tree in a single SQLite file, every browser tab talks to the same one local copy of gramps-web-api, and that server is deliberately configured to handle one request at a time (threaded=False in standalone/launcher.py) rather than several at once. That's not an accidental bottleneck — it's there because Gramps' SQLite backend can permanently lock the database if two requests hit close() concurrently (confirmed live: a real ~10k-object import followed immediately by a page reload reproduced it, and the tree never recovered without killing the process). Serializing every request through one thread sidesteps that race entirely, so the file is never touched by two requests at once no matter how many tabs you have open.

Where do I ask questions or report a problem?

Discussion happens on the Gramps Discourse forum; issues and pull requests against the gramps-connect repo are welcome. See Development.