Names Display Refactoring

[Uncle Buddy]

The practice of parsing strings like "Herbert Khaury #42" or "Tiny Tim (stage name)" is causing a growing mountain of unwanted complexity in both code and GUI. Putting the name and ID in the same GUI field was originally supposed to be a temporary convenience thing, and a little voice told me I'd be sorry. But knowing what kinds of hurdles have to be jumped in some apps to find a person's ID, I kept the feature since I liked the accidental co-feature where you delete a character in a name autofill input, then retype the character, to get the autofill to show the complete name including the ID. But then I have to write extra code to not show the ID all the time since it's ugly. But then when I detect IDs by testing whether the string contains "#", it isn't always there. And round and round she goes.

Detecting "#" or "(" in a name input in order to drive logic also means the user can't use these characters in a name, which would normally be reasonable, but seemingly reasonable restrictions can prove undesirable in edge cases. I have to get rid of this runaround with the display name. It would be better to display a nametip on all names. Instead of displaying "Joe Blow (also known as)" for an a.k.a., you just display the a.k.a. and have a nametip, so when you point at most names the tip will display something like "#42 birth name" but if there's no birth name, something like "#56 also known as" will display in the nametip instead.

There will have to be separate inputs for the ID and the name. Currently you can get the name to fill in by inputting either the name or "#42" for example into a name field. That feature could remain as long as the ID is filled into a separate ID field.

Using the FocusOut event to trigger actions is often tricky because focus can be tricky, but I can't stop using it with my insta-change table cells, because comparing self.original with self.final is too important to the design, that is, comparing what's in the cell when you focus into it vs. what's in the cell when you leave it. Since focus events are already wiggly, I have to try to put nothing in the field to complicate the situation beyond that.

I have to refactor this name thing completely, it keeps getting messier and buggier and harder to extend. For one thing, you should not have to parse names to get an ID; the name and ID and widget are in the dict, and if not, they should be. There should be a birth name key:value, an alt name key:value which is only used as display name if birth name value is blank, and alt name might have a default value if it's also blank.

If anyone thinks I am guilty of not planning things ahead, that's sorta true of the first draft, slightly less true of the second draft, etc. I'd hate to take the spontaneity out of my encroaching senility by making perfect plans in advance, and as a programming neophyte I am only just learning how planning a feature that I've never tried to write before is even possible. But enough yik-yak, on with the show, slow by slow.

The moral of the story is, "Complexity in coding is like a fractal that keeps growing, except it's not pretty." When adding a feature breaks existing features, it's time to simplify.

[Uncle Buddy]

The purpose of adding functionality to the autofill is that before, the autofill string was something like "Ronnie Webb #6" so the person's ID was supposedly always available. The availability becomes questionable, however, when a lot of hurdles have to be jumped to uphold the use of two separate pieces of data in one string, especially when the separate information is already stored separately in the database anyway, as it should be, and should be accessed separately instead of mooshing it into one string and then trying to get it back out again. Getting it out is easy, but having it available whenever it might be needed is another story.

What's needed is a reference to a person ID whenever a person autofill fills in with a name string. If "John Smith" autofills, then there has to be code backing this up so that the ID is also available instantly. For example, if there's more than one person named John Smith in the tree, the user should be asked to clarify which one is supposed to autofill. I've finished a simple dialog which lets the user select the right John Smith without looking up the ID manually with the search dialog, but if the user needs more information in order to decide which, he can press a SEARCH button instead of the OK button on the dialog so all the John Smiths will display together in a different dialog showing the parents, birth & death dates of all the John Smiths besides just their respective IDs. The person search dialog has been created and recreated at least three times, and will be back in working order one of these days, but it has to be adapted to every change made in the underlying data collections.

The good news is that a separate ID field hopefully won't be needed after all, since the autofill has already proven to be usable for user input consisting of any stored name or alt name, ID number sorts of things, or even Treebard's unique ID number for that person. The main advantage to not having an ID field in the Change Current Person section is that it means the same exact kind of autofill can be used for all person inputs, with no modifications to the underlying code. This simplifies the code considerably besides making the interface a lot easier to learn in an intuitive way; when the user tries something that should work, he will be pleasantly surprised that it does.

The refactoring of the person names feature is based on getting rid of a clunky system for looking up names with IDs whenever names are needed. Instead, all the people in the tree will load into a master dictionary when the app loads and reload when a person is added, deleted, or edited. Then when an ID is needed based on a name string, it's instantly available without further connections to the database, unless it's a duplicate name. In the case of duplicate names, a tiny dialog will open during autofill of an ambiguous name so the user can choose the right John Smith. Before, in order to pre-solve this edge case, autofill was providing "John Smith #31" to the input field and the program would have to try to extract the ID from this text whenever it was needed, for all names. This was wrong because it had the effect of treating every name as an edge case, and this led to blossoming complexity in the code. But the ID wasn't always available because, to avoid ugliness, the "#31" wasn't always displayed. Now when the "John Smith" fills into the GUI field, "31" is saved in a simple variable that will be instantly available for any number of purposes. The ID is generally of no interest to the user except when there are six John Smiths and the autofilling of a name string isn't enough. So only the John Smiths will now be treated as edge cases, and unique names will speak for themselves.

This refactoring might take a while, but knock on wood, my custom-designed autofill is miraculously still holding up and adapting nicely to greater demands, I guess because the code behind it is so simple.