-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
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.
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.
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.
Yes — Family Trees → Import... takes a Gramps XML (.gramps) or GEDCOM
(.ged) file, same as the real deployment. Just don't treat it as your
only copy — keep a backup regardless, the way you should for any tool
still under active development.
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.
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.
Gramps XML (.gramps) and GEDCOM (.ged) — the same formats Gramps
Desktop and gramps-web use, so a tree can move freely between all three.
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 smalllocalStorageUI 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'ssaveAll()). 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.
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.
Discussion happens on the Gramps Discourse forum; issues and pull requests against the gramps-connect repo are welcome. See Development.
Gramps Connect is part of the family of Gramps-based software.
Using the app
- Overview
- Installing
- Deploying
- Messaging
- GOQL (advanced search)
- Gramplets & Add-on Store
- Data Model & Editing
- FAQ
Building & contributing