Can someone explain what it does? The assortment of people does not seem to be terribly predictable. It appears to build a disordered submenu of people. Most seem like close relatives. But in my testing, there’s been odd ducks.
For my mother, the list is 10 people: mother, brother, sister, 8th cousin once removed, son, son, sister, father, maternal uncle, brother. (That’s both parents, all siblings, half the children, plus 2 arbitrary) For my father, there are 17 people (Again, both parents, all siblings, half the children, but 9 arbitrary … most of whom I don’t immediately recognize.) When I load my Pseudonym tree, it has the menu dimmed out. (The “Father” has 4 generations of ancestors with 30 people and 4 generations of descendant with 12 people.)
as an expert in Python code, Gtk toolkit and the Gramps genealogy software and its source code; fully explain the following logic to generate a “Related” submenu in the Pedigree charts. My interest in not in the GUI nor the use of the “Related menu item” once generated. I want to know how it decides which persons to include in the list and how it orders them.
item = Gtk.MenuItem(label=_("Related"))
no_related = 1
for p_id in find_witnessed_people(self.dbstate.db, person):
# if p_id in linked_persons:
# continue # skip already listed family members
per = self.dbstate.db.get_person_from_handle(p_id)
if not per:
continue
if no_related:
no_related = 0
item.set_submenu(Gtk.Menu())
per_menu = item.get_submenu()
per_menu.set_reserve_toggle_size(False)
label = Gtk.Label(label=escape(name_displayer.display(per)))
per_item = Gtk.MenuItem()
label.set_use_markup(True)
label.show()
label.set_halign(Gtk.Align.START)
per_item.add(label)
per_item.connect("activate", self.cb_childmenu_changed, p_id)
per_item.show()
per_menu.append(per_item)
if no_related:
item.set_sensitive(0)
item.show()
self.menu.append(item)
# Add separator line
item = Gtk.SeparatorMenuItem()
item.show()
self.menu.append(item)
# Add history-based navigation
self.add_nav_portion_to_menu(self.menu, person_handle)
self.add_settings_to_menu(self.menu)
self.menu.popup_at_pointer(event)
return 1
This code generates a “Related” submenu in the Pedigree charts for the Gramps genealogy software. Here’s an explanation of how it decides which persons to include and how it orders them:
Person Selection:
The persons included in the “Related” submenu are determined by the find_witnessed_people() function. This function likely returns a list of person handles (unique identifiers) for individuals who are considered “related” to the current person[1].
Ordering:
The order of persons in the submenu is based on the order returned by find_witnessed_people(). The code iterates through the list of person handles in the order they are received[1].
Filtering:
The code checks if each person handle (p_id) exists in the database using self.dbstate.db.get_person_from_handle(p_id). If the person doesn’t exist, they are skipped[1].
Menu Creation:
The code creates a submenu only if there are related persons to display (no_related flag)[1].
For each valid related person, a new menu item is created with the person’s name[1].
The name is displayed using the name_displayer.display(per) function, which likely formats the name according to the user’s preferences[1].
Connecting Actions:
Each menu item is connected to the cb_childmenu_changed callback function, which is likely responsible for handling the selection of a related person[1].
Additional Menu Items:
After the related persons, the code adds a separator and includes navigation and settings options to the menu[1].
The specific logic for determining which persons are “related” is not shown in this code snippet. It would be implemented in the find_witnessed_people() function, which is not provided here. This function likely considers various relationships such as witnesses, godparents, or other custom-defined relationships in the Gramps database[1].
My only comment is that this seems like a very expensive list of people to compute for being a menu item. I would suggest removing it from the menu, and adding a filter for this selection (if there isn’t one already). Later, that could be turned into a “business logic” function for additional speed (if that proposal is approved). Even then, it might be too expensive for a menu item.
It seems like a Quick Views submenu item would be far more useful in the charts. (Since Quick Views are persistent, allowing Person Editors in the list to be opened in sequential order.) And, if someone could explain the use of this witness list, maybe the “Related” could be converted into a “Witnessed” QuickView report.
I’ve never used this functionality but in testing it just now, one of the ‘related’ group of people are those people that share an event.
This became very noticeable to me because one of the shared events I use is for census records that I cannot find for the person or family. I use the same event for anyone I cannot find for that year. The Related option pulled in the hundred-plus people sharing the event.
I’d not explored/used this functionality before today either. I can confirm that ‘Related’ refers to anyone who has shared an event with the active person. So ‘Related’ does not equate to ‘Witnessed’ except when a role in the shared event is specifically ‘Witness’. If a ‘related’ person is selected, then all events associated with that person are displayed in the events gramplet side bar. Likewise all associated forms can be displayed which will enable one to display the shared event details.
At the very least, this Related menu item needs a better label.
What do you suggest?
Something like “Shared Experiences” or “Compatriots” or “Companions”? (Fellow Participants, Fellows, Associated, Fellow Attendees)
By the way, the “Copy” in the same Charts context menu is special. Consistency would lead one to expect the Person object will be copied to the Gramps clipboard.
But this “copy” uses the OS clipboard, not the Gramps clipboard. And it copies the Person’s vital statistics instead: Name, birth & death.
Were you able to determine if there was any interaction between Active, Home and Indicated persons?
That context menu definitely changes… based on which person is indicated by the mouse pointer when the right-click occurs. And the Active Person is the base of the chart. And the Home Person can be completely off-screen.
So, I wonder if there is any kind of triangulation when building the Related submenu?
I’ve had another peep at the ‘Related’ list and for my data set it includes the contents of the spouses, (full) siblings, children & parents lists. I’m not clear as to why it would be useful to consolidate the lists. More useful would be to reduce the list to other shared (non-familial?) events. However, exceptions would then be necessary for other participants in marriage. baptism and death events.
As to the title for a reduced list, I think ‘Compatriots’ is too broad, ‘Companions’ doesn’t really encompass, for example, a guarantor, defendant or licensee type role. ‘Shared Experience’ is closer, but ‘Associates’ is also a good umbrella for individuals with roles in shared events. Individuals linked by the Associate feature do appear on the ‘Related’ list.
