Refactoring is going on

[Uncle Buddy]

A while back (weeks or months ago) I started out to refactor the date validation procedure. I got most of the way done with that when I started bumping into code that my new refactored code would need to interact with. Bad, old code.

So I've been working ever since to refactor major portions of the code using my new subgenius-level intermediate beginner skills. The difference is vast. I'm particularly happy with the new events table which I've written over from scratch. This is at least the third major refactoring of the events table and by far the most radical change. The last version was horrible, even though it worked fine. Of course, before I finished that project, I ran into some code that the new events table procedures would need to interact with. Bad, old code...

So refactoring is going on all across the app and most of the code I've already posted is going to get considerably more than a facelift. I like to start over from scratch because I'm still learning fast and I don't want to copy my old ideas when I refactor. The result is always much cleaner and less convoluted, easier to understand and more capable procedures.

I'm just finishing up my new custom combobox widget. Come to think about it, that "bad old code" that I bumped into when I was trying to write a New Place Dialog was none other than the semi-configurable ttk.Combobox. In this refactoring I have the high and mighty goal of replacing every single ttk widget and never using one of them again. This is the "Toykinter" project.

In the past I've also worked on replacements for the unconfigurable Windows title bar and menu bar. So Windows will act as only an operating system instead of dominating an important part of our application design: how apps look. No doubt a lot of apps already use their own title bar because if they don't, their color schemes have an interloper. For now I've put this goal on hold, as the "good riddance to ttk" project is more important.

My main project--genealogy software called "Treebard GPS"--is supposed to be highly accessible to senior citizens, and I am of that breed myself, old as the hills. Treebard color themes are easy to create and change, and then along comes ttk and tries to say that Windows wants me to have stark white backgrounds in my Combobox entries. Only a year ago "dark mode" was still getting trashed as a radical idea. Things are changing fast, as in "we've stared at bare lightbulbs long enough, thank you very much". Later today I hope to unveil my new Toykinter combobox, which has functionalities that the ttk.Combobox never dreamed of, and hopefully more can be added.

[Uncle Buddy]

I ended up taking a longer detour than expected when I couldn't solve one of the problems with the Combobox due to the interloper, Windows' title bar. I got back to my old unfinished title bar and window border module and finished that. Several times. It looks like it's going to work just fine, at least I'm happy with it so far. This makes for a more fully configurable and easily configurable app. It's important that the user can change colors and do it easily. And effectively. I've been amazed to find that there's not one genieware out there (let me know if I'm missing something) that will let you change the color of your fonts. So if you choose a dark background, forget about trying to read the words on the screen.

The new combobox is working well and I'm happy with that too. I already have a tabbed notebook widget that does some things that ttk.Notebook doesn't do, like letting you put the tabs on the bottom, and of course making it any color you want. The ttk.Notebook, since it's ttk, is a struggle to configure because it is dependent on Windows themes. So you have to change your theme to one that allows you to use the options that are always there in classic Tkinter. When you get to ttk the options start to disappear without warning.

At one time I had a dropdown menu mostly finished and I don't remember why I stopped working on it. When I get to that part of the refactoring I might take another detour to finish that, since the Tkinter menu bar again uses Windows colors if I recall correctly.

But for now I'm back on track with the new place dialog, trying to stay focused on the events table so I can get that all working and put up a Github repository. I won't do Github till I have something substantial to share, and I've decided it will be substantial enough to share when I can show a completely functional events table. All nine columns will be able to get data in and out of the database before I move to a Github repository and stop posting code here.

Actually there are two events tables on the person tab, which is the front page of the app. The main events table is for dated events. The other one is for undated events and it can be hidden behind the picture area or it can be visible, the two can be toggled in the same space. I call undated events "attributes". Some things are meant to stay in the attributes table but anything can be moved to the events table just by adding a date to it. If you want to take something out of the events table and put it in the attributes table, just remove the date, or move it to the Particulars column instead of the Date column, and it moves to the other table automatically. I broke the events up this way because I've used genieware that puts undated and dated events in the same table, and then sorts the table by date. The result is ugly. You want to read a table that's sorted by date and have it make chronological sense. I suggest that estimated and approximate dates can be added to get something into the events table if no exact date is known. Treebard lets you mark a date as estimated, approximate, or calculated. I suggest using "est" for dates you're just guessing at, and "abt" for imprecise dates that you do have some sort of a source for. There are also ranges and spans.

While I'm suggesting things, I'll mention the picture area. There's room for a good-sized picture on the person tab. I suggest putting a picture in there for every person in the tree who is important to your research. If there's no picture of the person, I suggest using instead an old-time photo or drawing of the area where they lived. This adds a lot of life to the page. I will provide generic picture placeholders though, and I promise they will not be pink clipart cartoons for girls and blue ones for boys. I'll use something from an old newspaper for example. But the design I've been working on gives you the choice of displaying the attributes table instead of a picture, if there's no picture. They're both in the same tabbed notebook so you can choose which tab you want or let Treebard use its default which is to show the table if there's no picture. You can also provide your own generic pictures to use for people who you have no photo of. You can even find yourself some nice pink and blue cliparts if that's what you want to do.

Well this has been a rambling post. I turn 65 in a few hours so I let my mind wander from time to time, hoping to not wear the dang thing out before I'm finished with it.

[Uncle Buddy]

It looks like I started out to have a little fun refactoring the dates validation procedure in early February. I ran into code that needed to be refactored first, more and more of that, creating a chain reaction of refactoring. I stopped to deal with health and other issues. I started Treebard v. 0.0.0. I started another project called Cwrwgl. I started github.com repos for my projects.

Finally today, after refactoring the events table (twice?) and lots of other stuff, I finished an infinitely simpler and more practical version of the dates validation procedure. I can't believe how much easier it was to write this code the third time. As usual I didn't bother to look at previous versions for the most part, not wanting to import bad old ideas when my new improved state of beginnerhood might prefer to think up better ideas.

The events table is finished except for linking assertion functionalities to the sources column. I deleted a column that was making me old, because it contained too many functionalities, redundant data, and it was making me old. So the events table has only 8 columns now.

Next I will put the rest of the front page (Person Tab) back together, as shown in screenshots elsewhere on this blog. After that comes the cherry on top of the whipped cream: the sources/assertions functionality. I've been saving that for last.

When all that is done, I might move into a study of GEDCOM. Or start coding relationships. I think GEDCOM might be more important, because if data can't be gotten in and out of a genieware, it won't get used much.

With the front page finished and the existing code refactored, and the sources/assertions doing something, Treebard GPS will be coherent and testable. Far from finished, but that will mark a big day for me. I might get crazy and drink two cups of tea that day.

[Uncle Buddy]

This refactoring project started ten months ago and I am uploading the results to Github right now. Here are some of the things that have been accomplished by the refactoring.

The app works like an app now. Its various parts communicate with each other and work together. This is a coherent, testable working model. The database is now part of the Github repo. A simple command will import it into the program.

There are no ttk widgets in the project anymore, nary a one. I've replaced ttk.Notebook, ttk.Combobox, ttk.Separator, ttk.Sizegrip with easily and fully configurable widgets. The Windows-themed window border and dropdown menu have been replaced with fully configurable widgets. No more party crashers down at Themes-R-Us. If you want a dark mode, it will not have a white stripe running through it for a dropdown menu, and it will not have some Windows-theme-colored title bar. Entries and Comboboxes will not have white backgrounds unless you ask them to.

Font size, font family and font color are easily configurable, app-wide, in seconds. You can change background themes and create your own themes, in seconds.

You can input dates freestyle and they'll be displayed according to your chosen format.

You can make new people, give them a variety of names, search people by any part of their name, create events and attributes, and more. There are separate viewing galleries for images of people, places, and sources so you don't have to put them all in one big pile.

Everything has been painstakingly designed and redesigned and redesigned to be easy to use, uncluttered, yet powerful with detailed and complex data storage which does not translate into scary user interface. Treebard looks easy to use, and it is. It's not perfect and never will be, but it's almost good enough for me to use for data entry, and I'm picky about user interface. I made this program because I don't like any of those that already exist. See my other post of today for the only near exception to this sentiment.

Many design changes have been made since I last posted screenshots of Treebard, and many more are planned. Nothing is finished yet, many parts are not started, but if you can install Python, you can test this code and get a feel for the Treebard experience after 3-1/2 years of full-time work. If you're over 8 years old, you can install Python.

More information is available at the repo in the ReadMe file.