Treebard & UNIGEDS Do List July 2024+

[Uncle Buddy]

OFFICIAL TREEBARD AND UNIGEDS DO LIST:
Last updated August 22, 2024
I worked full-time+ on Treebard and UNIGEDS from July 15, 2018 to August 25, 2024 and didn't want to do it anymore. Here's what's left of two very old to-do lists, after most of the items therein were just deleted as they had either been done already or had become irrelevant. This list is in markdown format and has bookmarks, so it can be saved as markdown to display in a web page.

OFFICIAL TREEBARD AND UNIGEDS DO LIST:
Last updated and prioritized July 2024
I worked full-time+ on Treebard and UNIGEDS from July 15, 2018 to July 15, 2024 and didn't want to do it anymore. Here's what's left of two very old to-do lists, after most of the items therein were just deleted as they had either been done already or had become irrelevant. This list is in markdown format and has bookmarks, so it can be saved as markdown to display in a web page.

# DO LIST

## Contents

__[Pinned](#Pinned)__
__[Assertions](#Assertions)__  
__[Charts Tab](#Charts)__  
__[Colorizer](#Colorizer)__  
__[Combobox](#Combobox)__
__[Contacts Tab](#Contacts)__
__[Copy Tab](#Copy)__  
__[Database](#Database)__  
__[Dates](#Dates)__  
__[Do List](#Do)__  
__[Files](#Files)__  
__[Fonts](#Fonts)__
__[Gallery](#Gallery)__  
__[GEDCOM, Import & Export](#GEDCOM)__
__[Graphics Tab](#Graphics)__  
__[Links Tab](#Links)__
__[Linux Version of Treebard](#Linux)__    
__[Menu](#Menu)__  
__[Messages](#Messages)__  
__[Mousewheel](#Mousewheel)__  
__[Names](#Names)__  
__[Notes Dialog](#Notes)__  
__[Person Tab](#Person)__
__[Person Maker](#"PersonMaker")__
__[Places](#Places)__  
__[Preferences Tab](#Preferences)__  
__[Projects Tab](#Projects)__  
__[Reports](#Reports)__
__[Relationship Calculator](#Relationship)__        
__[Right Click Context Help Menu](#Right)__  
__[Roles Dialog](#Roles)__  
__[Root Module](#Root)__  
__[Search](#Search)__  
__[Sources](#Sources)__  
__[Splash Screen](#Splashscreen)__  
__[Statusbar Tooltips](#Statustips)__  
__[Toykinter](#Toykinter)__  
__[Transcriptions](#Transcriptions)__

## Pinned<a name="Pinned"></a>

*  `conn.execute("PRAGMA foreign_keys = 1")` wherever you have `conn.commit()`.
*  The instructions for easily recreating unigeds.db every time a database table schema is changed are at the top of new_tree.py.
*  If you use Github but don't don't much about it, keep your own system of backups on your own computer and dropbox account till you know how to fix mistakes in git.
*  Treebard and UNIGEDS are created by me, Scott Robertson, a U.S. expatriot who lives in Southern Mindanao and also goes by the names Professor U. d'Guru, Uncle Buddy, and Luther Rangely. I am the creator of Treebard and UNIGEDS, not the owner, except for the name "Treebard" which you don't have permission to use unless I give it to you in writing. Do what you want with this code. I don't work on it anymore. It's in the public domain. Donations are accepted at treebard.com.

## Assertions<a name="Assertions"></a>

*  Add tab to assertions TabBook for generic/compound assertions so imported assertions don't have to go into a note. Other geniewares make it easy and natural to lump a bunch of assertions into one block of text, encouraged by GEDCOM's habit of linking TEXT to SOUR instead of PAGE. These compound assertions could be saved as-is in Treebard if there was a place to display them, and the user could, if he wanted, do them over as individual assertions linked to citations.

## Charts Tab<a name="Charts"></a>

*  I never started this feature. Pertinent data can be exported with GEDCOM and imported to an app that makes charts.

## Colorizer<a name="Colorizer"></a>

*  Swatch_canvas: adding to mousewheel scrolling didn't work last time I tried it. Don't mess up existing features to make the mousewheel work here, this feature is a masterpiece as is. Arrow navigation autoscrolls the canvas already.

## Combobox<a name="Combobox"></a>

*  def show_selected_types(self): #  IN main.py
""" This is run by a button but it would be nice to finish the
`Combobox.combobox_selected` so it would change instantly when a
different type is selected in the combobox.
"""

*  When scrolling if the mouse strays off the scrollbar the dropdown sometimes undrops.

## Contacts Tab<a name="Contacts"></a>

*  I never started this feature.

*  Contacts are not importable or exportable. They are private, people have to ask if they want someone's contact information.

## Copy Tab<a name="Copy"></a>

*  Make it possible to copy sources and other elements from one tree to another so the user doesn't have to re-enter them. This has already been done for places.

## Database<a name="Database"></a>

*  Keep unigeds.db purely for primary genealogy data. To create a new tree, copy unigeds.db as a tree name. Code can add tables to the copy for data related to secondary features, the app, and the user. When Treebard adds such tables, it appends _tbd to the table name. A separate database tbard.db is used for app data that doesn't need to reference anything in unigeds.db. This way, any genieware vendor who uses UNIGEDS as its back-end can transfer data to any other genieware vendor who uses UNIGEDS as its back-end. In this way UNIGEDS or better can grow into a replacement for GEDCOM. "Don't share GEDCOM, share the whole tree."

*  The instructions for easily recreating unigeds.db every time you change a table schema are at the top of new_tree.py. I make all my schema changes in sample_tree.tbd and delete all the other test trees I start, because updating test trees to a new schema becomes a burden.

*   Many SQLite examples are in open_and_use_sqlite.txt which is in the `etc` directory.

## Dates<a name="Dates"></a>

*  A date calculator is the first feature I wrote, when I started learning Python. The code is so bad that I never looked at it again, but I'll send it if you want. If I can find it. It worked for the most part. There are no doubt plenty of date calculators you could import to your project, but I don't like doing that because it's more fun to write custom code that will only work for my application, and when it's finished, I know why it works. And no one is gonna change it on me.

*  Refactor dates.py using immutable variables and short functions

*  When changing date format in PREFERENCES > DATES tab, then go to events table and CTRL+F5, the dates don't reformat. You have to restart the whole app to see the new formatting.

*  Add a calendar tool to the tools manu so that if you have a newspaper article dated June 14, 1927 and it states the subject died last Tuesday, you can open the tool and go to 1927 and get the date of last Tuesday. There are no doubt plenty of perpetual calendar tools that could be imported but the standard Python libraries are preferable as Treebard avoids dependencies in order to not scare off beginning developers.

## Do List<a name="Do"></a>

## Files<a name="Files"></a>

*  File utilities are housed in base.py or opening.py.

## Fonts<a name="Fonts"></a>

*  Move the PREVIEW and OK buttons to top in the font tab so they can be seen and used when trying to make very large fonts

## Gallery<a name="Gallery"></a>

## GEDCOM, Import & Export<a name="GEDCOM"></a>

* Currently if the user makes a mistake in selecting same places (differently spelled place names that correlate to the same place_id like "United States" and "USA") using the UpgradeGEDCOMPlaces feature, by leaving out a same place before clicking NEXT, if he goes back and unhighlights the places he put in without their partner and correctly rehighlights all matches this time and clicks NEXT again, the matches all go in the second time but the first (incomplete) set of matches is not replaced, so the place_id that was created for the first set of matches still exists, and a different place_id is created for the second set of matches/place names. The first set should be deleted or else when the user tries to unhighlight grayed (already entered) place names, he should be told to click cancel and start over. The former is much better if it can be done.

* When there are 2 places named Dallas and 1 place named Dallas City, and the user wants them all to have the same place_id, if he first clicks Dallas, both will turn red, then he can ctrl-click Dallas City and it will turn red. This works fine but if he first clicks Dallas City, then ctrl-clicks Dallas, the 2nd Dallas doesn't turn red, so he will have to find each Dallas and ctrl-click it separately. The ctrl-click should work the same as the plain click, it should turn all instances of that string red so the user doesn't have to search for them by eye.

*  Do something about REPO, CALN and friends. Currently I've stopped supporting REPO and CALN since I replaced the means for saving them with a way of making a source note. I didn't have the patience to make the GEDCOM do something like that, and repositories are about the research, not the historical elements, so it's not a primary feature and I just disabled the GEDCOM import and export from doing anything. Except the part that was already going into the exceptions report regarding locators (CALN).

*  Import pandas and read the file in chunks, in RAM, and concatenate back together to get the resulting file, but keep it in RAM. Don't keep saving it over and over by different names, just do that once at the end. This is Tamura Jones' prescription to me: "Programs that manipulate GEDCOM in memory are the programs that import GEDCOM quickly. Writing to disc is what slows everything down." https://www.youtube.com/watch?v=97t9zmXeyD0

*  Make import & export work from all relevant buttons i.e. on the Treebard dialog and on the app text menu at top.

*  Make all the GEDCOM dialogs modal.

*  Keep track of file names created (temp files like .lux, head.ged, data.ged) and delete them at the end, also add the deletion of these files to the reset() method.

*  Test with many more real GEDCOM 5.5.1 files. Much of what I did was with manually edited .ged files to test specific cases. What's needed is to actually seek out problems that need to be addressed. Testing of the GEDCOM import and export programs was limited by lack of infinite time to do it.

*  Look for things that are not being concatenated. What about places e.g. "United Sta"?
       if idx in self.concatenations:
           value = self.concatenations[idx]

## Graphics Tab<a name="Graphics"></a>

*  Add a ROTATE button on graphics tab and a Rotate class in graphics.py.

*  Change graphics so that anything appended to a file name is very short, rename Jeremiah's photos and any long name photos in sample_tree.tbd. Use relatively short file names. Treebard doesn't mind long names but some Windows utilities in the file-sharing process still have a limit on the length of file names in 2024.

## Links Tab<a name="Links"></a>

*  This feature has not been started. The user should be able to select any element and get a list of other elements that this element is linked to.

## Linux Version of Treebard<a name="Linux"></a>

*  My setup for using Linux is a dedicated CPU with Linux Mint installed. A KVM switch so two monitors/keyboards/mouses are not required, just press a button to switch from Windows computer to Linux computer, and use an external hard drive or flash drive to save docs that either computer can use. If you use a virtual machine instead of a dedicated CPU, in my experience VMWare is reliable and VirtualBox is not. VirtualBox works until it comes to the all-important feature of sharing files between Windows and Linux. VMWare's guest feature works fine and VirtualBox's guest feature is terrible, hard to fix, and when it finally starts working, there's no reason to think it will keep working. Besides acting this way for me, it has a bad reputation in this respect, and always has, which is why I switched to VMWare.

*  Tkinter works on Linux. You have to install the Tkinter separately, unlike Python for Windows, but it only takes about 2 seconds to do. There will have to be some changes made to the code, for example, mouse buttons are referenced differently. I've never done this so that's all I'm gonna say.

*  If you're hooked on Notepad++ as an editor, as I am, here are some alternatives since NPP only works on Windows. Any editor without a macro recorder is not an alternative, from my point of view. I have tested only the first of these suggestions: 1) Get Sublime Text. It's not free but it works and is full-featured, delivering reminders from time-to-time that you're supposed to pay for it. 2) Install Wine and run NPP in Wine. 3) Try Geany. It either has a macro recorder or used to, I'm not sure which. If it's "used to"... maybe an older version is available?

## Menu<a name="Menu"></a>

*  UNDO is a useful feature which I never started.

*  Icon menu--Leave the whole set of icons in the repo unchanged due to its license. These icons were chosen because they're 2-color. Multi-color icons with gradients are just mud to anyone over the age of 59, and to certain personality types which refuse to memorize what extraneous little blobs are supposed to signify. Don't add text under the icons, the tooltips work fine and screen space is too precious to state the obvious. The words on the screen should be about the user's ancestors, not about the app, as much as possible. Extra reading to do on the screen is mental noise.

## Messages<a name="Messages"></a>

## Mousewheel<a name="Mousewheel"></a>

## Names<a name="Names"></a>

## Notes Dialog<a name="Notes"></a>

*  Notes need to be linkable to more elements. This has only been done for events, assertions, and names. See notes_links table in unigeds.db for the possibilities.

## Person Tab<a name="Person"></a>

## Person Maker<a name="PersonMaker"></a>

## Places<a name="Places"></a>

## Preferences Tab<a name="Preferences"></a>

## Projects Tab<a name="Projects"></a>

## Relationship Calculator<a name="Relationship"></a>

*  There's a database table in unigeds.db called `kin_types`. Try to see if this table can be used to create a relationship calculator.

*  Before I wrote my first line of code I imagined a system for a relationship calculator that uses this "realization" if that's what it is: there are only four relationships. A chain of relatedness could be created using these codes:

  A: current person
  B: parent
  C: child
  D: partner
  E: sibling

*  For example: aunt or uncle would be "current person has a parent who has a sibling" or ABE. Grandparent would be: "current person has a parent who has a parent" or ABB. First cousin would be "uncle has a child" or ABEC. Etc. I don't know if this has a practical application, but it seems to cover stepchildren, half-siblings, etc. I'll send the spreadsheet if you're interested. I never wrote any code to use this.

*  There is a tree traversal thing with nodes and leaves and stuff (tree as in programming algorithms, not family tree) which would supposedly work for family trees but I couldn't find an example of applying it to genealogy.

*  The closest common ancestor principle is probably what other relationship calculators are using. I never got started on this feature.

## Reports<a name="Reports"></a>

*  Just use AI. I consider genealogy reports obsolete. Who wants to read identical sentences over and over when we can pore over the spontaneous hallucinations of a machine instead?

## Right Click Context Help Menu<a name="Right"></a>

*  The right click menu is a good feature but not finished. If I were going to keep working on Treebard, the next thing I'd rewrite would be the right click menu or "rcm" as it's sometimes called in the code. The tuples in messages_context_help.py should be replaced by dictionaries. These tuples currently contain some blank values and other values that should be blank or deleted since I'm out of time or energy for rewriting features (July 2024) and don't remember exactly how this code works so I'm afraid to just delete things but maybe that's what I should have done in regards to help topics that were once needed for widgets that no longer exist. What's needed is probably a better way for the right click menu code to reference widgets, such as storing them in a dictionary and changing the references when the widgets no longer exist. The statusbar tooltips probably have some of the same deficiencies as the right click menu. The existing right click menu feature has three specific deficiencies. 1) widgets made in a loop can be given a context help menu (e.g. `self.rc_menu.loop_made[deleter] = role_edit_help_msg`) but if those widgets are destroyed, there will be a Tkinter error when you try to use the right click menu on the new widgets that replace the destroyed ones. See the PlaceDupes class for an example of this problem. 2) areas which are redrawn with new content will display their right click menu only on a freshly loaded app. When content changes, the new widgets probably have no binding to the right click menu. 3) Help topics have only been added on a sample basis. Many widgets are lacking them. I've gone through and edited the existing topics so they're accurate for Treebard in July 2024.

*  Right-click menu: wrong message is opening because two lists were zipped but the lists had been manually messed with since I forgot they would be zipped so the wrong message is now paired with the wrong widget. Rewrite this so that it doesn't rely on two huge lists being changed manually then zipped because the widgets change all the time so this will always cause problems. Possibly the whole dictionary should just be hard-coded so nothing has to be in any special order. Why Is It Necessary to have all widget refs in main.py instead of in user_formats.py, events_table.py, etc. Better to keep the lists smaller so if there's a change or a problem, there is less affected.

*  Add a button that goes to the main user manual which is an offline-usable website with screenshots and other illustrations. Add a tooltip to the button: "For the illustrated version and more details, press to open the User Manual."

## Roles Dialog<a name="Roles"></a>

## Root Module<a name="Root"></a>

*  To start Treebard, run the module called "treebard_root_041.py" or whatever it becomes if someone changes it. The number 41 denotes the fact that in the six years I worked on Treebard, I made vast changes to the design of this or that at least 41 times. 400 is closer to the truth.

## Search<a name="Search"></a>

*  Add to PersonSearch dialog: checkbox "Speed Up Search" with tooltip "Search will begin after three characters are typed. Don't select this for number searches." Select it by default. (It already works hard codedly.)

*  Use the PersonSearch class as a model for the search tab where the user can search places, people, sources, citations, assertions, notes, widget text, etc.

## Sources<a name="Sources"></a>

## Splash Screen<a name="Splashscreen"></a>

*  The splash screen no longer exists. I moved its content to PREFERENCES > GENERAL and added a photo of my friend the late, great Marvin Siefken. He was once the circulation manager for the big newspaper in Minneapolis/St. Paul. You can use my photo for anything you want as long as you keep Marvin Siefken's name in the title. The photo was taken in the yard of the UPS building in Stockton, California in 1989.

## Statusbar Tooltips<a name="Statustips"></a>

*  The statusbar tooltips are supposed to be non-intrusive and useful instructions on how to use hovered widgets. They're on the statusbar so they don't cover what the user is trying to read or do. They're black so they don't force the user to look at them.

## Toykinter<a name="Toykinter"></a>

*  Toykinter is a name I once used for the widgets created to replace ttk widgets. Do not pollute my laboriously consistent code base with ttk widgets. The standard Tkinter widgets are easy to format and the ttk widgets were never needed and are no longer more modern looking than the original Tkinter widgets. The only ttk widgets I needed were Combobox and Notebook, so I replaced them with my Combobox and TabBook. Getting ttk widgets to conform to your color scheme is a matter of pitting ttk.Style against Windows themes to see which one wins. Either way, your color scheme code is the loser. If you don't think Tkinter is good enough, rewrite Treebard in Dearpygui and Python, or just switch to Delphi FMX which will work on all platforms, is consistent with Python's "batteries included" philosophy, and autocreates your .exe for you on the fly while you work. And it's a compiled language so it's faster than Python. If you just want your project to work in Windows, you could use Delphi VCL instead.

## Transcriptions<a name="Transcriptions"></a>

*  Treebard saves person names as a whole, not split into first/middle/last, because that's how names actually work. One full name references one person. This prevents pointlessly complex code. "Bernard Herbert Jackson" refers to the same exact person as "Bernard" or "Herbert" or "Bernard Jackson". The full name is not a compound name.

Treebard saves place names like "334 Park Drive, Glenwood Springs, Garfield County, Colorado, United States of America" as five separate places and five separate place names--that's ten ID numbers--and an additional ID number for each nested place defined by the user when adding places via the GUI. Unlike the case with person names, "Glenwood Springs" and "Colorado" refer to two completely different places. The nested place name is a compound name. That's how Treebard treats it.

Naturally, GEDCOM gets this exactly backwards, splitting person names into parts for no reason and treating Jackson, Mississippi, USA as one place instead of three.

In order to handle place name transcriptions accurately in gedcom_import.py and gedcom_export.py, we have to look into splitting the transcription. Is it even possible? In other alphabets, it won't be possible or worth doing, if that alphabet doesn't separate single places within the nested place by commas.

As for completing this feature in Treebard, a further complication: my code was wrong. The queries (or one of them) is saving a place name ID, which is either correct or well-intentioned, while the SQL query schema has a nested place ID. I already replaced the nested_place_id column in the transcriptions table with a place_name_id, but the other considerations mentioned above gradually occurred to me and it became apparent that this is not going to be redesigned and fixed in an hour or two.

I'm out of time but I suspect that the transcription table row needs to link to a place_id OR a nested_place_id AND a place_name_id. Objections and problems loom in my mind but it's lunchtime and I only have enough time to comment out the code, not enough time to fix it. AFTER LUNCH EDIT: When changing the light bulb didn't keep the light from flickering, I was about to tear out a section of ceiling to check the wiring when I realized I hadn't even considered changing the light receptable.

What's needed here is a nested_place_name_transcription table similar to nested_place. If a transcription can be broken down into comma-delimited parts, each single place will have its own transcription, linked by transcription_id foreign keys in nest0, nest1, etc. If a transcription can't be broken down into comma-delimited parts, the transcription as a whole will have to be linked with a nested_place_id foreign key in the transcription table.

I would add these things to UNIGEDS but I think the sanest thing to do with transcriptions would be to use notes for them. This is an application of the "don't start what you can't finish" principle. GEDCOM made approximately zero-plus progress on transcription types by defining about two of them. The right place for things that will never be pinned down is in a note linked to a place name. I just added a transcription_id foreign key in notes_links, and that's the sanest thing to do for now.

Not that I want to be limited to doing sane things, but at this point I'm not motivated to get wild and crazy with this stuff, I've done enough.