families table rewrite done for now
Jun 5, 2024 19:30:58 GMT -8
Post by Uncle Buddy on Jun 5, 2024 19:30:58 GMT -8
Looks like it took almost two weeks to rewrite the nuclear families table in the GUI (again), and there will be fixes to do in the future but it seems to be working for now.
During this period of time, other features were created also. ID tips now appear when you point at names in the families table, to supplement the kin tips that appear in the events table when you point at a multi-person event.
I just spent a few days getting the back, forward, and home icon buttons to work in the ribbon menu at the top of the app. These are still more ways to change the current person. The home button changes the current person to person #1. The back and forward buttons change the current person according to a history of visited persons. This is a nice feature for speeding things up when working on a few different people at once.
Besides these new ways to change the current person, you can also change to a person searched & found with the WHO button; by CTRL-clicking any name in the families table; or by entering a name or ID number of a person in the big input at the top of the app. This input, as well as any person input in the families table, can also be used to created a new person.
I tried to keep a partial list of hurdles that slowed me down as I worked on this rewrite. All of this probably amounts to either getting in a hurry, trying to be clever, or trying to write clean code or less lines of code instead of code that will be useful in a week when I've forgotten who wrote this stuff. Novice coders like me like to pretend they're doing rocket science, and end up with the wrong priorities. It's gotta be ten times more important to write readable, understandable, extendable code than it is to write clever code. For writing code that's just counting the eyelashes of our ancestors, it's usually not important to worry about saying it with fewer lines of code, but it's always important to worry about the fact that this code will be... like... "who wrote this drivel???" to its author in a day or two. Especially when the author is as old as I.
--I had used lists for the table row data instead of dicts, in prior versions. Dictionaries are faster to read for unordered data. Dictionaries are usually easier to read for humans trying to write, rewrite, and finish code. Lists make you look up all the indexes all the time. Dicts, on the other hand, tell you what you're looking at when you're looking at, if the keys are named usefully. Lists are faster to read for ordered data. So each row should have been a dict and the collection of rows should have been a list of dicts.
--I used two sets of similarly-named lists like `partners_data` and `self.partners_data` with a different collection of stuff in the latter. Like the wise man said, you are not wise until you know how stupid you are. Having reached the age of disillusionment, my plan is to stay stupid, to see if the wise guy was right.
--I wasted another day on a feature that's been plaguing me ever since the first time I wrote the families table feature: null partners. By accident I discovered long ago that a couple could have a null partner in it, and a null partner could have children with the real partner. But SQL is built around ID numbers, and nulls are not easily delineated. Obviously there have to be ID'd people with no name like Brian's wife in "Brian Thomas married to ______". Finally I realized that having both ID'd people with no name AS WELL AS null people without an ID is worse than unnecessary, so I got to gleefully evict the null partner from the code. I'll also have to autocreate unnamed partners for ID'd couples. This might not be necessary in other geniewares, but in Treebard we have four kinds of parents: biological, adoptive parents, foster parents, and guardians. My means of creating alt parents so far has been to require the user to add an adoption, fosterage, or guardianship event. This autocreates fields in the families table for the alt parents' names to be entered. When the adoption event is created, a corresponding couple_id needs to be created so the row will have a reason to exist in the table. Putting nulls in place of the two person_id foreign keys in the database's couple table is possible. It's done for parents but in Treebard there are always parent fields whether parents are known or not. Partners are different, like alt parents, the partner field doesn't exist till created, but unlike alt parent, the partner is complicated by the existence of children corresponding to that partner. Due to the nature of Python and the way I designed the families table to show at once every family the current person had, multiple null partners ended up having their children combined into one family. So I will be autocreating unnamed partners in some cases, at least till the next rewrite, and hopefully it will not be too annoying.
--A lot of time has been spent, through the various rewrites including this one, trying to give the user a choice of which couple events and children to unlink a partner from, when the user tries to delete a partner from the GUI's family table. I had this working in one or more of the versions, but this time around it was annoying me so much that I decided, conveniently enough, that the user would rather completely delete and then have to partially reconstruct a couple/family once in a while than to always be forced to analyze options on a dialog that always opens when a partner is deleted. Now that I've canned this feature, if a partner is deleted, the current person keeps the couple events and the children, while the deleted partner is unlinked from the events and kids but not deleted from the database. This is easy for the user and usually correct, no dialog opens, and I'm happy to lose another nitpicking feature so that Treebard's important and unusually detailed features don't get lumped in with nitpicky features that shouldn't have existed anyway.
--I am so disgusted by every version of Windows since version 7 (which was kinda perfect), that I finally broke down and took the Linux plunge. I bought a separate CPU, having already tried and not liked having a virtual machine in an only CPU. (If you do this, do yourself a favor and use VMWare, not VirtualBox, according to my experience.) I'm waiting for a KVM switch to be delivered so I can use the two CPUs at the same time with the same monitor, keyboard and mouse. I like Linux Mint. It was easy to get it working with Tkinter and SQLite but I did not yet plunge into making Treebard work on Linux. I don't know how hard that will be, so I just got the basics set up and we'll see how it goes. For one thing, the mouse buttons are referenced differently in Linux. I also want to rewrite Treebard in DearPyGUI and Delphi FMX, if I live long enough and don't burn out or lose my mind first. As for Mac or OSx or whatever they call that other operating system, I pity the fool who invented the smartphone, because of where his tormented soul is now burning for what his invention did to the children of the world, including the 3rd world where I live. Fortunately I am joking (sort of) but I seriously have no plans to make Treebard work on Apples. Someone else can do that. Reimbursement for the new Linux-devoted CPU will be happily accepted at treebard.com/donate.htm.
New code is coming, but I won't say "soon" because it would be a jinx.
During this period of time, other features were created also. ID tips now appear when you point at names in the families table, to supplement the kin tips that appear in the events table when you point at a multi-person event.
I just spent a few days getting the back, forward, and home icon buttons to work in the ribbon menu at the top of the app. These are still more ways to change the current person. The home button changes the current person to person #1. The back and forward buttons change the current person according to a history of visited persons. This is a nice feature for speeding things up when working on a few different people at once.
Besides these new ways to change the current person, you can also change to a person searched & found with the WHO button; by CTRL-clicking any name in the families table; or by entering a name or ID number of a person in the big input at the top of the app. This input, as well as any person input in the families table, can also be used to created a new person.
I tried to keep a partial list of hurdles that slowed me down as I worked on this rewrite. All of this probably amounts to either getting in a hurry, trying to be clever, or trying to write clean code or less lines of code instead of code that will be useful in a week when I've forgotten who wrote this stuff. Novice coders like me like to pretend they're doing rocket science, and end up with the wrong priorities. It's gotta be ten times more important to write readable, understandable, extendable code than it is to write clever code. For writing code that's just counting the eyelashes of our ancestors, it's usually not important to worry about saying it with fewer lines of code, but it's always important to worry about the fact that this code will be... like... "who wrote this drivel???" to its author in a day or two. Especially when the author is as old as I.
--I had used lists for the table row data instead of dicts, in prior versions. Dictionaries are faster to read for unordered data. Dictionaries are usually easier to read for humans trying to write, rewrite, and finish code. Lists make you look up all the indexes all the time. Dicts, on the other hand, tell you what you're looking at when you're looking at, if the keys are named usefully. Lists are faster to read for ordered data. So each row should have been a dict and the collection of rows should have been a list of dicts.
--I used two sets of similarly-named lists like `partners_data` and `self.partners_data` with a different collection of stuff in the latter. Like the wise man said, you are not wise until you know how stupid you are. Having reached the age of disillusionment, my plan is to stay stupid, to see if the wise guy was right.
--I wasted another day on a feature that's been plaguing me ever since the first time I wrote the families table feature: null partners. By accident I discovered long ago that a couple could have a null partner in it, and a null partner could have children with the real partner. But SQL is built around ID numbers, and nulls are not easily delineated. Obviously there have to be ID'd people with no name like Brian's wife in "Brian Thomas married to ______". Finally I realized that having both ID'd people with no name AS WELL AS null people without an ID is worse than unnecessary, so I got to gleefully evict the null partner from the code. I'll also have to autocreate unnamed partners for ID'd couples. This might not be necessary in other geniewares, but in Treebard we have four kinds of parents: biological, adoptive parents, foster parents, and guardians. My means of creating alt parents so far has been to require the user to add an adoption, fosterage, or guardianship event. This autocreates fields in the families table for the alt parents' names to be entered. When the adoption event is created, a corresponding couple_id needs to be created so the row will have a reason to exist in the table. Putting nulls in place of the two person_id foreign keys in the database's couple table is possible. It's done for parents but in Treebard there are always parent fields whether parents are known or not. Partners are different, like alt parents, the partner field doesn't exist till created, but unlike alt parent, the partner is complicated by the existence of children corresponding to that partner. Due to the nature of Python and the way I designed the families table to show at once every family the current person had, multiple null partners ended up having their children combined into one family. So I will be autocreating unnamed partners in some cases, at least till the next rewrite, and hopefully it will not be too annoying.
--A lot of time has been spent, through the various rewrites including this one, trying to give the user a choice of which couple events and children to unlink a partner from, when the user tries to delete a partner from the GUI's family table. I had this working in one or more of the versions, but this time around it was annoying me so much that I decided, conveniently enough, that the user would rather completely delete and then have to partially reconstruct a couple/family once in a while than to always be forced to analyze options on a dialog that always opens when a partner is deleted. Now that I've canned this feature, if a partner is deleted, the current person keeps the couple events and the children, while the deleted partner is unlinked from the events and kids but not deleted from the database. This is easy for the user and usually correct, no dialog opens, and I'm happy to lose another nitpicking feature so that Treebard's important and unusually detailed features don't get lumped in with nitpicky features that shouldn't have existed anyway.
--I am so disgusted by every version of Windows since version 7 (which was kinda perfect), that I finally broke down and took the Linux plunge. I bought a separate CPU, having already tried and not liked having a virtual machine in an only CPU. (If you do this, do yourself a favor and use VMWare, not VirtualBox, according to my experience.) I'm waiting for a KVM switch to be delivered so I can use the two CPUs at the same time with the same monitor, keyboard and mouse. I like Linux Mint. It was easy to get it working with Tkinter and SQLite but I did not yet plunge into making Treebard work on Linux. I don't know how hard that will be, so I just got the basics set up and we'll see how it goes. For one thing, the mouse buttons are referenced differently in Linux. I also want to rewrite Treebard in DearPyGUI and Delphi FMX, if I live long enough and don't burn out or lose my mind first. As for Mac or OSx or whatever they call that other operating system, I pity the fool who invented the smartphone, because of where his tormented soul is now burning for what his invention did to the children of the world, including the 3rd world where I live. Fortunately I am joking (sort of) but I seriously have no plans to make Treebard work on Apples. Someone else can do that. Reimbursement for the new Linux-devoted CPU will be happily accepted at treebard.com/donate.htm.
New code is coming, but I won't say "soon" because it would be a jinx.