The Recent Repo Commit...

[Uncle Buddy]

I'll use this thread when I make feature commits to the github repo.

I have finished, for now, the parents area at the top of the family table. The table is at the top left of the current person tab, above the events table.

The family table now includes the ability to input and delete biological parents of the current person as well as adoptive parents, foster parents, and guardians. To make the inputs for these latter "alt parents", first create a new fosterage, adoption, or guardianship event. The inputs will appear and will autofill with existing persons or assist in making new persons if desired.

To unlink a parent from the current person, just delete the name from the family table. Unlike some genieware, Treebard doesn't assume you want to unlink the current person from both parents when you unlink from one of them. This is because Treebard treats individuals as individuals. Treebard also does not refer to parents of a child as "spouses" unless you tell Treebard they are spouses. The kin type feature lets you call partners anything you want. There's no coding-by-gender except for the biological mother and father.

I'm trying the unlink feature without an extra dialog for now, but one could be added if it ends up being confusing. To delete the parent person from the tree, first change the current person to the one you want to delete. (The feature for deleting a person from the tree doesn't exist yet.)

The version just committed to github is pretty well functional although the family table isn't finished yet. Beneath the parents section is a partially functional section for the current person's partners, and indented under each partner are the children from that partnership. Then at the bottom, an input will be coded to allow creation of new children and partners.

When the family table is finished, the app will function much more as a cohesive unit, but presently a lot of it works pretty well. Well enough to play with, anyway, to see what it's like.

[Uncle Buddy]

Today's commit is described in detail in several posts I just made under the thread "Partners in the Family Table", which is in the category "Thinking Out Loud".

The code is getting closer now to a functional whole, although the family table isn't finished. The child details section (indented under partners who have children with the current person) is the next stage of the coding process. After that I'll tackle the input at the bottom of the table which is used with either the ADD PARTNER or ADD CHILD button depending on which radio button is selected. After that, a feature will be added that will let the user change the current person to any name in the family table by double-clicking the name. Then a large do list of straggling details will be taken on. That should complete the first draft of the family table, clearing the way for the next major feature to be created.

EDIT: I forgot to export the databases to .sql files this time, so if that's a problem let me know and I'll provide the files.

[Uncle Buddy]

Don't try to use today's commit, it will be an aborted branch which I'll get back to later. First I have to replace complex systems of string parsing that I've been using to get IDs and to get display names when there's no birth name. I will replace the odd name display with nametips, i.e. tooltips which show the person's ID and the name type of the displayed name such as "birth name" or "stage name" when you hover the name with the mouse. This is going to be a big refactoring with effects everywhere so I have to start a dedicated branch for it called "names_refactor". I'll push current changes and start the new branch, and hopefully be able to finish the family table after that.

[Uncle Buddy]

The refactoring of names-related code throughout the app is complete for now and I'll be pushing the changes to the repo today or tomorrow. The families table shows some functionalities but it's in a state of disarray, by which I mean that fixing one thing breaks another. That's because there have been too many interruptions, there was too little knowledge of what was needed (i.e. too little planning) before the first few drafts. So I will start the new branch as a refactoring of the code that runs the family table functionalities. I like the current UI for the families table, so it will be kept and finished.

Most of the names used in the app so far will be in the family table so I'll wait till that's finished to create the nametips. When you point at a name with the mouse, a tooltip will appear which gives the person's ID and name type such as "pen name" or "A.K.A.". This lets Treebard display whatever name is available if no birth name is available.

With the refactoring of names, a person's ID number no longer appears after his name in the same input. This simplified things, I was able to strip out chunks of no-longer-needed dithering in the code. The procedure for finding names and IDs when needed was totally revamped. This was a lot of work since the name inputs are all autofills and the autofills didn't want to get changed much. All the work is now done up front and centrally so that when a name or ID is needed, the footwork has already been done, the needed values are waiting and available, and the code is much simpler.

[Uncle Buddy]

Today's commit represents a partial functioning of everything on the families table. But there are some problems, such as wrongly opening Treebard error messages that don't do this when the app is freshly loaded, but do it after some changes have already been made in the families table. (When trying to edit parents.) I'm interrupting the testing of the families table to experiment with restructuring the database by combining three tables into one. I think the separate existence of the tables `finding`, `findings_persons` and `persons_persons` can be gotten rid of by combining the three tables into the finding table. If it works, it will make debugging much simpler. If it doesn't work, it wasn't supposed to.

[Uncle Buddy]

Today's commit again focuses on a partially functioning families table, like the last commit, except now the database structure has been vastly improved by simplification. The commit includes a file called sample_tree.sql which can be imported into SQLite, becoming sample_tree.tbd, the database I use every day for development.

[Uncle Buddy]

Yesterday's commit mainly included a completely new way to redraw the whole app with a new color scheme. The old way still worked but relied on many calls to a function that queried the database to get the new color scheme. Once I added cohighlights (see below), too many calls to this function doubled the app's loading time so I refactored that code. Now, Treebard's custom widgets still inherit from Tkinter widgets like before, but the so-called special event widgets, which change colors in response to events such as mouse-hovering, don't have to make an extra query to the database. Instead, these classes have a variable at the class level instead of the instance level so for each widget class with special events, only one set of colors has to be redefined instead of for each instance of that widget.

Another new feature is cohighlighting inputs on the persons tab. The families table at the top has a lot of person inputs and the events table has an events column listing event types experienced by the current person. Event types for couple and offspring events now highlight along with their corresponding persons in the families table when hovered with the mouse. For example, hovering the word "offspring" in the current person's events table will highlight that word as well as the name of the corresponding child in the family table above. It works in reverse too: if you hover the child's name in the families table, the offspring event will highlight also. Or you can hover a marital event in the events table, and the partner name corresponding to that event will highlight in the families table, and vice versa. Or you can hover the birth event for the current person and the parents' names will highlight in the families table and vice versa. This feature lets the user get the big picture about a multi-person event instantaneously without visually sifting through names or events in either table, without looking things up in another tab or dialog, and without my having to provide a kin column in the events table. I canceled that feature some time ago because a kin column in the events table is needed only for some of the events and works differently than the other columns and makes the table too big and therefore is hard to code and a wrong way to do things because it makes the GUI unsymmetrical in its functionality.

As for what's newly broken or still broken in this commit:

The fonts reconfiguration still works but never was properly finished and is less finished now. I'm planning to finish that next.

Manually redrawing the persons tab with CTRL+S still sort of works but not as well as it used to. It's getting too complicated and I'll also be refactoring that code in this next branch.

The families table is still not finished. Parents and partners work pretty good but children have barely been started. The children that are in the sample tree right now were put there by creating new people and then changing them to the current person and giving them parents, or else by adding them to the database manually with SQL commands.

(The sample tree is once again available in its current version as a flat file `etc/sample_tree.sql` that can be imported to a binary database file called `data/sample_tree/sample_tree.tbd` using the SQLite console.)

[Uncle Buddy]

I just made a commit which included the following improvements:

1) The `redraw()` function was cleaned up, consolidated and reorganized. This runs on CTRL+S for instance. A SAVE button isn't really needed since the database is self-saving by its nature, but Treebard's SAVE functionality incorporates new changes into redrawing the persons tab. Pressing CTRL+S is no longer necessary, it runs automatically at the right times, but it's still there and might come in handy. If not, being able to click SAVE or press CTRL+S can still reassure the user who's used to saving his work frequently.

2) The reconfiguration of user preferences for font family and size was simplified, improved, and finished.

3) The whole color scheme reconfiguration code was refactored and this code is now finished, as far as I know, and vastly improved over the system that's been working well (off-and-on) for years, but was getting out of hand.

I've put a lot of time into giving the user the ability to easily change the important parts of his app's appearance: colors and fonts. Unlike some apps which are massively reconfigurable (such as Gramps with it's Gramplets, i.e. added/subtracted widgets), I consider it my problem to figure out what the app should look like, and then let the user change colors and fonts reliably and globally with a very few buttons clicks. This might sound like what other apps supposedly do, but let me assure you, the other apps do nothing of the sort. It's Treebard's philosophy that most users don't want to design the app for me. They want to do genealogy. So there's not much the user can do with Treebard except genealogy. For users who want to spend days and weeks tweaking features and customizing the app, I recommend Gramps. For users who want to know how to use the app the first time they look at it, without doing tutorials or reading manuals, I recommend Treebard.

[Uncle Buddy]

Today's commit isn't because anything has been finished. I'd checked out a families table branch but ended up working on importing GEDCOM instead, so I just wanted to checkout a properly named branch.

Today's commit does contain some preliminary working GEDCOM import stuff but also several miscellaneous files, this is not a well-organized commit.

[Uncle Buddy]

No changes in this commit. Just getting off the GEDCOM treadmill back to the meat and potatoes of Treebard proper.

[Uncle Buddy]

In this commit, I just refactored to break self.families_data up into self.parents_data and self.progeny_data. Little else was changed.

[Uncle Buddy]

After nearly six months of work, I've committed a version of Treebard with a fully functional families table. This table is on the current person tab and lists his parent, all foster/adoptive parents, all partners by way of marital events and offspring, and all children with all partners including unknown partners. The person fields in the families table can all be instantly edited. Double-clicking any name in the table changes the current person to the clicked person. Tooltips show the ID and displayed name type for any person hovered.

The only thing I don't like about this first finished draft of the families table is that tab traversal order is funky. It works on load, i.e. you tab through the table and focus goes where you expect. After an edit, the table redraws, and tab traversal is still correct but first you have to relocate focus by clicking the mouse where you want to start, or by tabbing back into the table. Ideally, if you edit the mother, then tab out of the mother field, the focus should go to the next field. This doesn't happen because the table redraws after each edit. A whole day was spent trying to fix this, but it's a complex problem due to a design decision made early on and retained through several rewrites. As it stands, undesirably complex code seems to be needed to workaround this.

The design decision leading to the problem was this: the parent fields are permanent, and all the other fields are created as needed, and destroyed on redraw after an edit in the table. This messes with the tab order after a redraw since Tkinter doesn't allow references to widgets that no longer exist. The solution is probably to destroy the parent input fields when the other fields are destroyed, and recreate all the widgets at the same time during redraw. This would be an easy fix, I think, but it's on the do list for later and I'll be moving on to the assertions dialog branch. The families table seems to be perfectly usable at the present time, and of course there will be bugs found in it from time to time but I don't think there are any more seriously bad ones. The only nuisance I know of is having to reposition the focus within the table after an edit, when the user might be trying to tab through making edits in field after field consecutively. Which isn't generally how users are gonna use the table anyway, so fixing this is on the back burner.

[Uncle Buddy]

The purpose of today's commit is just to stop work on the assertions dialog so I can take some time to concentrate on rewriting the places functionality. This is not a useful commit, unless someone wants to see a nearly empty dialog open up when clicking the SOURCES button in the conclusions table.

[Uncle Buddy]

This commit includes the hopefully completed rewrite of the places functionalities, and a lot of changes to the data structure.

The app is pretty coherent at this point, and the next step is to finish the assertions dialog, which I'd been documenting as a video log also, in case any beginning coders like me wish to see a whole feature created from scratch.

Included in today's commit:

--All the types tables including color schemes were moved to treebard.db which is seen equally by all the user's trees. This way, if the user creates a kin type, event type, etc., he won't have to redo it every time he starts a new tree.

--AUTOINCREMENT was removed from all database table schemas so SQLite will be able to re-use primary key ID numbers from deleted table rows. The primary keys are still made automatically but the AUTOINCREMENT was extra, unnecessary, restrictive and more costly to run.

--The new Duplicate Places Dialog is closer to perfection than the old version, and even more to the point, it works. It might still need some tweaking but for now it will work and it will allow me to try and draw to a close this Chapter One of Treebard Development four-year sprint... to its rightful finish line.

I'm hoping to continue work on Treebard GPS indefinitely, but at a slower pace. I'm still currently working at it full time and probably will continue to do so till the assertions dialog is functioning and useful. Before jumping back into the assertions dialog, I might make a video tour showing what Treebard is able to do right now, as well as some unrelated tasks and a wee break from writing code. There are a few things I have to catch up on.

Thanks for dropping by.

[Uncle Buddy]

Committed half-finished assertions tab. Displays OK. Still to do: make NOTES button work which includes long-procrastinated look into why you can't open a blank notes dialog (probably something simple); testing notes dialog with assertions tab and making sure it links the note to the ?assertion since prior to this it's only been used to link notes to ?findings or something in the conclusions table; repository dialog works to display repositories and locators and to make new of each; changed database structure so all types tables and color schemes are now stored in treebard.db instead of in the tree.tbd database file; .sql flat files are out of date as regards schemas except for charles_d._gregory_family_tree.sql and same.tbd which are currently the model instead of sample_tree.tbd and default_new_tree.db which both need to be caught up; treebard.db is caught up but forgot to dump it to .sql file. Will do that right now since many changes were made but essentially what's missing from treebard.sql are the types tables and color schemes table. I'll actually post treebard.sql here right now also since I am in excrutiating pain like stiff neck but worse and it may be a while before I get back to this. Also still to do in current new branch assertions_tab: make the four EntryAuto rows able to accept edits and put them into database, and add inputs for new assertions, sources, citations to the assertions tab, also see current do list at bottom of the module with _root in its name, which is the file you run to run Treebard.