Post by Uncle Buddy on Mar 8, 2022 1:38:19 GMT -8
The first draft of the families table is finished through parents and partners of the current person, leaving the children of each partner to finish as well as an input under the table where the user can enter names for new partners and children of the current person. In the description below, remember that everything in this table is supposed to be from the viewpoint of the current person only, not the family unit or the couple unit as such. Limiting the scope of the table prevents confusion and makes it harder for the user to mistakenly edit something with mysterious consequences that would then have to be tracked down and reversed one at a time.
In the parents section, I chose to make it possible to 1) add a parent to a blank parent cell or 2) delete a parent link from the current person by simply deleting the name of the parent from the cell. Trying to make existing parents editable in any other way would complicate the code and violate the principle of limiting the user to editing a person by first making that person the current person.
As it turns out, the code for partners was close to finished, and here's how that currently works in regards to the set of children indented under each partner, if any.
Each partner has a row flush left in the table. Under each partner is a set of children, if any, and the child rows are indented so the user can see the family unit(s) that have been entered for the current person. If needed, a scrollbar will appear, and it will be needed frequently because all the current person's partners and children appear in the table at once, a feature which might be unique to Treebard. Treebard does this because Treebard feels that the most basic element of genealogy is the individual (a biological unit) instead of a couple or family (social units). In order to tell the individual's story, we want to display all his partners and children together at the same time. Partners and children are sorted logically by any dates associated with marital events and childbirth events.
This gets interesting when there are children of the current person whose other parent is unknown. There are a few ways to handle this.
1) If the user enters nothing for some of the current person's children, these children will be lumped together under a partner row with no parent name.
2) But what if the user knows or suspects that the children didn't have the same two parents? In that case, the user can enter underscores, a question mark, or whatever symbol they prefer to create a person in the table with an unknown name. For example, Jed has two children and we don't want them lumped together because we have no reason to believe they had the same mother, and we don't know who either mother was. The user can change each child in turn to the current person and enter "_____" (or whatever he prefers) for each child's mother. Then there will be two separate unknown partners on Jed's family table and each will have one child.
3) If the user prefers to keep the two children under one unknown partner, Treebard will already have them listed this way. Codewise it's important to realize that this unknown partner is not a person in the database, and this happens because Python's `None` is being used as a dictionary key. This could be coded out of the GUI by replacing `None` with a programmatically-created key, but the result would be one unknown partner for each child. I'd prefer to let the user make this decision for himself.
I'm aware of the argument that users should not create fictitious names for their unknown people, and that's why I suggest using "_____" for each unknown person. By using the same symbol for all unknown persons in the tree, the user will make it possible to search all unknown people by searching names equal to the symbol or string of symbols.
Relatedly, it is bad practice to use words instead of symbols to denote a missing name. The common practice of using "unknown" or "UNK" when a name is unknown could conceivably lead a genealogist who is unfamiliar with English to assume that a person's name was actually "Unk". Since that is my name, I'd prefer you didn't use it to refer to missing people.
In the parents section, I chose to make it possible to 1) add a parent to a blank parent cell or 2) delete a parent link from the current person by simply deleting the name of the parent from the cell. Trying to make existing parents editable in any other way would complicate the code and violate the principle of limiting the user to editing a person by first making that person the current person.
As it turns out, the code for partners was close to finished, and here's how that currently works in regards to the set of children indented under each partner, if any.
Each partner has a row flush left in the table. Under each partner is a set of children, if any, and the child rows are indented so the user can see the family unit(s) that have been entered for the current person. If needed, a scrollbar will appear, and it will be needed frequently because all the current person's partners and children appear in the table at once, a feature which might be unique to Treebard. Treebard does this because Treebard feels that the most basic element of genealogy is the individual (a biological unit) instead of a couple or family (social units). In order to tell the individual's story, we want to display all his partners and children together at the same time. Partners and children are sorted logically by any dates associated with marital events and childbirth events.
This gets interesting when there are children of the current person whose other parent is unknown. There are a few ways to handle this.
1) If the user enters nothing for some of the current person's children, these children will be lumped together under a partner row with no parent name.
2) But what if the user knows or suspects that the children didn't have the same two parents? In that case, the user can enter underscores, a question mark, or whatever symbol they prefer to create a person in the table with an unknown name. For example, Jed has two children and we don't want them lumped together because we have no reason to believe they had the same mother, and we don't know who either mother was. The user can change each child in turn to the current person and enter "_____" (or whatever he prefers) for each child's mother. Then there will be two separate unknown partners on Jed's family table and each will have one child.
3) If the user prefers to keep the two children under one unknown partner, Treebard will already have them listed this way. Codewise it's important to realize that this unknown partner is not a person in the database, and this happens because Python's `None` is being used as a dictionary key. This could be coded out of the GUI by replacing `None` with a programmatically-created key, but the result would be one unknown partner for each child. I'd prefer to let the user make this decision for himself.
I'm aware of the argument that users should not create fictitious names for their unknown people, and that's why I suggest using "_____" for each unknown person. By using the same symbol for all unknown persons in the tree, the user will make it possible to search all unknown people by searching names equal to the symbol or string of symbols.
Relatedly, it is bad practice to use words instead of symbols to denote a missing name. The common practice of using "unknown" or "UNK" when a name is unknown could conceivably lead a genealogist who is unfamiliar with English to assume that a person's name was actually "Unk". Since that is my name, I'd prefer you didn't use it to refer to missing people.
Attachments:
" or "_____") will be found in the SAME family unit in the current person's family table. Which is not that bad in my opinion. The nice thing is that it accurately represents what's stored in the database. GUI-wise it's confusing but I think I'll keep it this way long enough to use it and see if it leads to any serious trouble. Complicating everything with a separate partner for each unclaimed child and marital event would be ugly. (A man I once researched had married at least eight women. Possibly to support his lifestyle conveniently, he lived in Nevada.)
