True enough. But it wasn’t what I was trying to say. I am trying to give information so people can weigh the tradeoffs for themselves. Then select the approach that gives them the most benefit for their needs.
Gramps uses an expensive “probably alive” calculation when the pertinent (vital statistic) life event cannot be found. Even though it might be expensive, the cost is worthwhile. It allows Gramps to avoid considering the whole tree. The awareness of fallback events extends the savings into the ‘fuzzy’ parts of the tree.
And the fallback events give visual (italics) feedback that both: the key statistic event is missing and offers an event date that would be in proximity for that missing date. It is more helpful than a blank.
But that feedback would be missing when using a custom event. Because the custom event will not be aware of it in the fallback calculation.
If you decide that you prefer a custom type, you do not necessarily have to lose the fallback feedback and other benefits… but it requires a bit of hacking.
For what needs to be changed in such a hack, there is an excellent example:
@DaveSch felt that Gramps should have a Stillborn event to simplify data entry. And added Feature Request 11554 to track his proposed solution and get it into the queue for inclusion in a future release. Because it added some compatibility with an unsupported GEDCOM 5.5.1 tag (although GEDCOM7 changes the approach), it was rolled into the Gramps 5.2 release.
But the file changes (a shown in for the related pull request on GitHub) can be very instructive on what needs to happen to :
- Data entry support
- flaga new ‘attribute’ for the automated Sphinx developer documenting system to index
- add a new pre-defined file type for an Event and give it an ID
- structure the choice into Event type sub-menu
- map the colloquial term and flag it for inclusion in the (Weblate) translation system
- add the preferred abbreviation for the term and mark it for inclusion in the (Weblate) translation system
- define if the event is a fallback of a particular vital statistic (e.g., birth, death, relationship)
While doing this change, Dave generalized the PeopleModel’s awareness of Fallbacks. Simplifying future extensions to the lists of Fallback types… now they will require only changing a single source code file. (He points out that Reports and Charts will need reviewing for their flexibility in Fallback awareness.)