I would like to be able to:
- Set multiple surname as default in person editor.
- Set a default surname origin type.
I think both things could be controlled via preferences.
Oooh.. That sounds interesting. There is a lot of Cultural support potential in extending the Surname Guessing to have more extensive options for onomastic conventions in genealogy and linguistics.
Back in 2021, my earliest experiment with scripting in SuperTool was a Surname Origin guesser for a Patrilineal culture with social conventions of “couverture” for mothers. So it also guessed Name Type of Married for Mothers as well as the Origins with a multiple surname form. It might be extended to also create an alternative “Birth name” for mothers too.
I’ve put a design plan together for Sub-Events. This differs in some ways than ideas mentioned, but it was designed to follow a Grampic Philosophy.
Feedback welcomed, and we can adjust the plan.
Tags that are not limited to colors. For example, various cross hatched patterns, emojis, and even very short text strings (e.g. “DNA”)
Some initial observations and questions…
What is the impact on Gedcom import and export? I know that some people have strong feelings about the inadequacies of the Gedcom standards but, as of now, I’m not aware of any other standard that has any traction. Do any of the Gedcom versions have any notion of super-events? If not, what happens on export?
What data elements will a super-event include? Notes? Gallery? Attributes?
BTW, am I right that super-events do not have Participants? In the described example, the baby that died enroute would not participate in subsequent sub-events like registering at Ellis Island.
Several Text reports and Web reports provide details on events and will presumably need to be modified to output the super-event and related sub-events in a coherent manner. While not needlessly complicate reporting of existing events. Could we have an example to show how these might be structured and formatted?
I’m interested in this proposal in that some of my family did a migration not dissimilar to the one described in the example. To me, one of the most interesting elements is that it was a group of families (seemingly all with inter-marriages) and there was a great deal of mutual support that was important to the process. Anything that would help me to understand the roles each played in such a loose group would be wonderful.
Craig
Thanks for the feedback! Some answers:
GEDCOM import/export
No GEDCOM version (5.5.1 or 7.0) has any concept of sub-events or event hierarchies. On export there are two options:
- Flat export (safe default): each event exports as a normal GEDCOM EVEN record, losing the hierarchy but preserving all data. Any GEDCOM consumer can read it.
- Custom tag (round-trip): add a non-standard _SUPEREV tag containing the Gramps ID of the super-event. Other applications ignore it, but a Gramps re-import could reconstruct the hierarchy. This is how other Gramps extensions that don’t map to GEDCOM are handled.
On import nothing changes — existing GEDCOM files have no sub-event info, so all events import flat with an empty super_event_list.
What data elements does a super-event have?
A super-event is a plain Event object — there is no new object type. It already has: type, date range, place, description, citations, notes, gallery, attributes, tags, and privacy flag. No additions needed. The hierarchy is purely a relationship between existing Event objects.
Do super-events have participants?
You are right, and it’s actually a feature. Participants are attached per-event via EventRef on Person and Family. So:
- The “Emigration 1882” super-event can list all 15 family members as participants.
- “Little Katarina dies (day 8)” lists only Katarina.
- “Register at Ellis Island” lists the survivors.
Nobody is automatically included or excluded by the hierarchy — researchers assign participants to each event where they were actually involved. A useful deferred enhancement would be a “roll-up” view showing all unique participants across all sub-events of a super-event.
Reports
Yes, text and web reports will need updating, but the approach is straightforward: when rendering an event that has sub-events, indent them below. A rough sketch:
Emigration, 12 Mar 1882, Rinteln, Germany
Leave home, 12 Mar 1882, Rinteln
Walk to Bremen (10 days), 12–22 Mar 1882
Arrive Bremen Harbour, 22 Mar 1882
Montebello Journey, Bremen → New York, 24 Mar–14 Apr 1882
Departure from Bremen, 24 Mar 1882
Bad weather, 29 Mar–2 Apr 1882
Little Katarina falls sick, 2 Apr 1882
Little Katarina dies, 4 Apr 1882
Emergency port call (repair), Hull, 5–12 Apr 1882
Arrive New York Harbour, 14 Apr 1882
Register at Ellis Island, 14 Apr 1882
Travel to Oregon (84 days)
By train
By wagon
Arrive Prineville, Oregon, 3 Jun 1882
Existing events with no sub-events render exactly as they do today — no regression.
Group of families traveling together
This is already well-supported by the design. Multiple Person and Family records can all hold an EventRef pointing to the same “Montebello Journey” event. Three families sharing the same voyage all appear as participants in that one event. Sub-events (the repair stop in Hull, the bad weather) are then visible under the shared voyage for all of them. The researcher can see at a glance who was on the same ship, who survived to Ellis Island, and which families were traveling together — without duplicating any events.
I hope the following will be possible in the not-too-distant future. Some of these ideas have already been discussed or worked on:
- Storing DNA matches as dedicated data objects.
- Objects/things for heirlooms, ships, etc., as dedicated data objects.
- Uncertainty of date periods. Currently, only instantaneous events can have uncertainty (using a range, i.e., between … and …, before …, or after …). Date periods (e.g., residence, using spans, i.e., from … to …, from …, or to …) don’t allow this. Ideally, I would like to store something like “from between February 1878 and September 26, 1879, until between July 2, 1890 and 1892.” I don’t think this is supported by GEDCOM, but I think there are also other Gramps features that aren’t compatible with GEDCOM.
- Storing evidence of citations in the database the way they are presented, independently of any interpretation, any combination with other citations to draw conclusions, or any usage of the interpretation/conclusion in events/people/etc. in the (main) tree of the database. I’m not sure, but I think this is related to shadow records of the GEDCOM Evidence Extension.
- An option to make filters tree-specific and include them in backups. (Even if only some simple filter rules are supported.)
Having some of these features in version 6.2 would greatly improve my workflow.
As Gramps is now moving to use the power of SQLite (json data) a simple DBA tool would be fine. It should be implemented in a way, so users, who don’t have a clue of what a RDBMS is, can use it.
We already have few DBA routines available like ‘Check and Repair Database’ and ‘Rebuild secondary indexes’.
Some features that might be implemented:
- Update statistics (PRAGMA optimize or ANALYZE) especially after imports
- Change memory buffering (PRAGMA cache_size). Recommendation based on data amount and physical memory available.
The extra super-event relation does not need to be more than an event property, similar to any other attribute.
As long as this is implemented as references only, I don’t see any impact on GEDCOM compatibility.
A Super-Event should behave like any other event: you can add participants to it, but it could also inherit participants from its sub-events.
In that sense it works as a collection event that also holds its own data.
Is this the right way to see it @dsblank ?
I added a small comment on your design plan on GitHub, nothing major.
Otherwise, I think the plan looks really good. This approach will allow for very advanced registration, and when the time comes, it should also be relatively straightforward to extend this into “Events on Places”.
On the event property point: Yes, exactly. A super-event relationship is just a field on the Event object — super_event_list: list[EventHandle] — the same way place is a field. No new object type, no special class. A super-event is a regular event that other events happen to reference.
On GEDCOM: Agreed. The relationship is stored as internal Gramps handles. On export those handles simply aren’t written to GEDCOM — the events themselves export as normal EVEN records and are perfectly valid GEDCOM. Nothing breaks; the hierarchy is just not representable in GEDCOM, which has no equivalent concept. So “no impact on compatibility” is the right way to put it.
On participant inheritance: Yes, with one clarification worth making explicit. In the data model, participants are not inherited — each event explicitly lists only its own participants. “Little Katarina dies” does not automatically add Katarina to “Register at Ellis Island.” That would be wrong.
What you are describing as “inherit” is better understood as a view or query feature: when you look at a super-event, the UI (or a report) can compute and display the union of all participants across it and its sub-events. “Collection event” is a good term for this — it holds its own data and also acts as a window into everything beneath it.
That roll-up display is deferred to a later phase in the plan, but the data model already supports it without any changes.
This sounds incredibly easy 
We can probably do that as an addon for 6.1.
I like this idea a lot! It should just be part of the Gramps XML.
Yes, this is the better way to explain it.
What I meant by “inherit” was not that the Super‑Event/Main‑Event/Root Event should get participants added to the event itself, but that these “container” events could display the participants of their sub‑events.
That combined view or collection of participants could then be used for research: reports, tagging, finding specific research targets, etc.
For example, if a family or person only appears in a single event during the time a ship is at sea, there is a high chance that additional documents or sources exist for their journey.
- If they are not registered under their original name at Ellis Island, where did they go?
- Did they change their name?
- Did they transfer to another ship for Canada or South America?
A combined participant view makes this kind of research much easier.
And of course, as you wrote, such aggregated views/collections can be added later as an enhancement in a future stage or version.
Regarding GEDCOM and the referenced handle: your earlier suggestion about using a custom tag is the correct way to support round‑trips.
And it brings a bonus: If other genealogy programs want to adopt the feature, they can simply use the same custom tag (wishful thinking).
For developers: PR for adding sub-events:
Apparently This user wants the same thing
https://gramps.discourse.group/t/auto-unfold-multiple-surnames/9703
I made a plan for developers (and others) to comment, suggest, and discuss to add these two proposed features:
Let me add a sack of my 5c.
Gramps already has logic to convert between calendars: Gregorian, Julian, etc. This logic is hardcoded inside Gramps. Factor it out into a standalone lib and make Gramps use it.
Why?
- There is hardly any good open-source lib for calendar conversion. Making that code available outside of Gramps will be of big help for everyone, even outside the geneo community.
- AFAIR, fixing a bug there once, the date-related logic is tightly coupled and hard to work with. Decoupling it will reduce complexity and make it more maintainable.
- Adding more logic there before refactoring further increases the complexity of that code.
-
Add a UI note that you can type dates, and especially the calendar name (
1800-01-01 (julian)).
Optionally make a video on best practices for data entries.Why?
I only figured it out after a Gramps contributor hinted to me that it’s possible. Improved my speed of data entry dramatically.
-
Replace the dumb search requiring selection of the category with the smart one, where the category is picked based on the entry. With a fallback to adjusting the category manually.
Why?
Many entries are self-explanatory:
S0055is the source,F0006is a family, “My text” is the title in the citation search, or a name in some name search. Adjusting a category manually on pasting some IDs slows down the entry speed 2-3x.
FYI: Gramps tends to break the clipboard globally on my Win 11. The clipboard’d stop responding. I filed a bug about it a while ago, but it’s very non-deterministic and hard to debug/reproduce consistently. So FYI if someone notices the problem. Probably the underlying GUI libs, not Gramps per se.
TypeHints are a must all over the codebase. LLMs can do it reliably with no sweat. A day of coffee break while a capable agent covers the codebase.
Why?
It enables mypy and similar checkers, increasing the code quality and the overall safety.
It enables a new quality standard worth enforcing (and locking Python 3.14+ as a min requirement to support the latest hinting format that improves readability).
Allows enforcing mypy rules and reporting metrics similar to code coverage with tests.
Protocols around all the libs, e.g. the API is a must. See example: addons-source/NameSuite/name_processor/protocols/gramps.py at maintenance/gramps61 · gramps-project/addons-source · GitHub
LLMs will build them quite easily.
Why?
- Promotes proper decoupling.
- Greatly simplifies testing.
- Contibutors can can reuse them for proper dependency inversion.
Needs a button for quick Selected Person ↔ Root Person (i.e. DB owner) check, instead of manually picking myself every time.
Hope it helps
Just a small thing. I like to be able to see the Home Person (aka Proband) in the Statusbar.
It could be as simple as displaying the name in center of the statusbar, or if “Relationship with Home Person” is selected in Settings, then the Home Person’s name could be shown together with the relationship (e.g. grandmother’s grandmother of home-person-name).
tia
That’s an interesting idea. It does make the most sense when there is a relationship between selected person and the home person. But do note that finding a relationship could be an expensive operation. But could do the processing as a background process.
But I do wonder if putting the home person in the status bar when it never changes would just be clutter. Perhaps a mouse-over on the status bar could reveal it when needed?