I’ll change the filter rules to following names and descriptions to avoid confusion:
Patrilineal progenitor of <person>
Matches the earliest recorded patrilineal ancestor father.
Matrilineal progenitorix of <person>
Matches the earliest recorded matrilineal ancestor mother.
Y-chromsomal inheritance of <person>
Matches recorded descendants of person following Y-chromsomal inheritance patterns.
Mitochondrial inheritance of <person>
Matches recorded descendants of person following mitochondrial inheritance patterns.
Y-chromsomal inheritance of <filter>
Matches recorded descendants of a filter result following Y-chromsomal inheritance patterns.
Mitochondrial inheritance of <filter>
Matches recorded descendants of a filter result following mitochondrial inheritance patterns.
I won’t add the checkboxes to this set of filter rules, because I want them to follow stricktly the genetic inheritance patterns, but I can create new filter rules following the male or female lines or other inheritance patterns with an option for including non-biological descendants.
It makes clear that it is not making actual DNA searches and that the relationships are by Birth. Maybe expand the Description to include something like: "… the search results are the presumed Y-DNA results passed on by fathers to biological sons.
In choosing a Rule name, we need to keep the character limits of the interface in mind. We could get VERY explicit but the names need to be as terse as possible with the most critical criteria early.
Also, the convention seems to also require indicating the parameter. So the ‘of <person>’ portion wouldn’t be optional for the name
I experimented with adding the ‘Adopted’ sons to the SharedYDNA file. I named it ‘Male Line Descendants’. Besides changing the description verbiage, etc I added three lines of code.
for family_handle in family_list:
family = self.db.get_family_from_handle(family_handle)
for child_ref in family.get_child_ref_list():
child = self.db.get_person_from_handle(child_ref.ref)
if (child_ref.get_father_relation() == _("Birth") and
child.get_gender() == 1):
male_children.add(child_ref.ref)
if (child_ref.get_father_relation() == _("Adopted") and
child.get_gender() == 1):
male_children.add(child_ref.ref)
return male_children
Was hoping we could minimizing addition of rare use add-on rules that are a simple exception. The rules lists could become overwhelming very quickly. (And my selfish reason… And the documentation burden would be lighter too! Only 1 entry in the Add-on list page, 1 section in the Rule Expansions page, & 1 screen capture. Note that Rules haven’t yet been inserted in the Add-on List because we haven’t sussed out some oddities in the management of Rules.)
The primary use would be for biological relationships with the rare case including the adopted & hired womb babies.
So how about making the checkbox for the rare-case with the defaults being for the general case? The deselected by default checkbox might be ❏include all dependant relationships. (Although that still feels like awkward wording)
Yup, “by Committee” is pretty much the entire concept of Open Source!
That said, Matt is creating them and has final say on his contributions. But he’s welcome to choose when to tell us to shut up. I try to show my appreciation by adding them to the wiki so he doesn’t have to.
He has been graciously posting to the GitHub repository for others to try out. They haven’t gone through code review yet and are still at the ‘Potentially hazardous. Use at your own risk’ stage!
You have to know enough (be enough of a daredevil) to be able to install manually. Once they pass through peer/code review, then an admin will add them to the Update manager and installation becomes easy enough for everyone,
Hey @Mattkmmr
I just re-read the add-on Rules docs and noticed that we can’t credit your work properly yet. Add-ons are normally credited in the Add-On list. But add-on Rules are doing funky things with the Plug-in Manager. So Rules haven’t been added there yet.
It is currently an All-or-nothing proposition. You can’t install & de-install one. Gramps applies the changes to all downloaded Rules at the same time. I suppose you have a measure of control because you can choose not to download. But Rule downloads tend to be bundled in sets rather than individual rules. And groups of distinctly different rules don’t slot into the compact Add-on List Table cleanly.
So far, only you and Paul have posted Rule contributions. Paul’s got his fingerprints all over Gramps. (In a GOOD way, @prculley !) So what would you like us to do for your credit until there’s some solution for the Rules in the Addon/Plugin Manager section?
You need to look more closely. There is a source filter rule that I had a part in. In fact it was the first addon rule. Although I was shocked when Paul got it into a working form that he included me in the credits. My contribution was to copy existing code and get it configured to be used as a new builtin standard rule. He did all the work to make it an addon so it could be pushed out to the user needing it.
Sorry for missing your Contribution. That’s another reason Sam’s been trying to find a way to drive some sort of synchronization between that wiki table wiki & download manager. Its too easy to overlook someone’s significant efforts.
@DaveSch Wouldn’t it be a bit confusing to call this filter “Male Line Descendants” if it only includes male male-line descendants? From the name only I would have assumed it includes female male-line descendants too (videFilter for male-line descendants) Is there a reason why someone might want all patrilineal descendants (including adopted sons) but not daughters? Perhaps it would be more intuitive to have a filter that is called “Patrilineal descendants” that would include all male-line descendants (male or female) - and then the user could easily add the gender filter on top of it?
