History and Future of the Treebard project

[Uncle Buddy]

Today I finished refactoring my Treebard code to a new class-centered structure instead of the procedural coding style I'd adopted when I first started using Python. Putting everything into classes makes a big difference, almost self-organizing the code. Having tried coding with and without classes I'd say that there is a real need for a namespace corral bigger than a function and smaller than a module. Classes are just right for that. I once was determined never to write a class for code that wouldn't be repeated in more than one place. But the fact is, using classes imposes an order on the code and it has other benefits than providing a blueprint for code that is to be used repetitively. I am not an OOPer; I don't claim that "everything is an object". But now that I'm learning how to use classes, I love them. No more stupid pet tricks to solve namespace problems.

Here's a summary of how I got interested in writing my own genieware.

My parents were both interested in genealogy. My mom had a distant cousin, a Mormon who used to organize big family reunions. These were worth attending because my grandma's cousins were well-known writers and poets, and one of them was the forest ranger who took Smokey the Bear to Washington DC. They lived into their 90s and beyond, and their talks were the highlight of the reunion.

I started researching inventors of exotic compressed air engines & such in 1979 and around 2009 I started researching the backgrounds of these old-time inventors using genealogy resources online. I live in the Philippines so online research is about the best I can do. I fell in love with genealogy and have compiled trees for many inventors who I'm not related to. But the programs I could find for putting the names, dates, and events into a database seem unfinished and poorly designed, as if the developers were in a hurry to get something to market. I don't know why they bother selling a program for $20 to $60, it doesn't seem worth the trouble. I am looking forward to giving Treebard away when I have enough code written to bother.

I used a program called Genbox for a few years and enjoyed it but the program has long been unsupported and hasn't been updated in many years, so I bought Family Historian but didn't like it as well. In either case, inputting data, especially citations, is more tedious than it should be. In about 2015 I started the Treebard project, at first aiming to build a web app. But the problem of online security and servers and frameworks with multiple dependencies discouraged me and I set the project aside for a few years. The real problem was that I didn't know enough Python to carry through with it, even with Web2Py which is supposed to be the simplest of frameworks with no dependencies.

In 2018 I decided to make a standalone app instead of a web app and this opened everything up to me. I was still using Python and learned that both Tkinter and Sqlite come with the program. I started with a real easy GUI maker, then AppJar which introduced me to Tkinter. At the time I didn't know that Python was slower than compiled languages such as C++ or Go, but since I knew nothing about programming except how to write simple websites in HTML and CSS, Python was probably the right choice for me. When I found out how slow Python is, I decided to proceed anyway with building a "showcase for genieware functionalities" in Python and let real programmers fork the project and rewrite it in the language of their choice if they wanted to.

Just this past week I decided to start a real genieware project of my own (Treebard proper) based on the Python version (Treebard GPS). I will probably use C++ and Sqlite, and for a GUI toolkit I have chosen gtkmm. It will be slow going and I doubt I'll ever finish since I'm 64 years old and going blind but if there's one thing I need in my dodderage, it's a dang hobby and this is a good one as it is always challenging and I get to see the results take shape without getting up out of my chair.

In the past couple years I've probably spent 6000 or 7000 hours working on Treebard, starting over many times on the design, the code, even the basic concept until I found a format that I think should work for all kinds of genealogists, especially myself. I'm still a beginner at programming and will probably always be one but I never had so much fun sitting in a chair. At my age a chair is a good place for me. My only regret is not learning computer programming as a teenager since it seems to suit my personality pretty well.

For me and programming it's still early in the game, but I'd say the key to learning how to code, in my opinion so far, is the willingness to start over. This is why Treebard is going to be better than other programs. Developers seem to be going with their first impulse, putting out an unfinished application as Version 1, and then using that as a model ever after due to the backwards compatibility restriction that comes into effect when people start buying your product. This is why Treebard GPS is never going to be called a finished product. It is a showcase for functionalities: how should a genieware program do things. I hope it will inspire developers and users to expect a better user experience.

My pie-in-the-sky fantasy is a program that's so good no one will ever want to use a different program, thus putting GEDCOM completely out of the picture. Just share the whole program. So Treebard will be portable, requiring no installation, easy to share. But in reality I know that GEDCOM or some sharing utility will always be needed as no single program can cover all the bases for everybody.

[Uncle Buddy]

I've gone through a simple C++ tutorial and see no reason why I can't learn to use the program. My big problem is not writing code but installing programs. I've tried three different ways to install gtkmm and nothing works so far. I'm looking for a different GUI toolkit for C++ that comes with a Windows installer that actually works. That's what's so great about Python, its "batteries included" attitude. But a Python program will never run as fast as a C++ program.

Installing programs that don't come with a one-click installer that actually works... is beyond my current ability. It might be a long time till I know how I'm going to overcome the problem of getting to work on a C++ GUI. In the meantime, I appreciate Python all the more, and for my needs, it doesn't have to handle hundreds of thousands of database entries, I just don't do that kind of genealogy. Some genealogists won't be able to use a Python program for genealogy because they do a lot of importing and exporting of large databases. Probably the best person for converting Treebard GPS to Treebard version 1.0 is anyone but me. In the meantime, as I started to say, I am still gung ho on developing a showcase of functionalities, which is what Treebard GPS can be for any genealogist or genieware developer. And if worst comes to worst, if no one likes Treebard GPS, I like it and I can use it for my relatively small projects. I've worked on lots of family trees, and the largest only had maybe 4000 people in it, or less. I think Python can handle that, anyway I can't wait to find out.

But wait I must because I have a lot of work to do still.

[Uncle Buddy]

I looked into many C++ GUI toolkits and the like. I only found one that seems like it might be easy to install and well documented. Ultralight Pure-GPU HTML UI Engine for Desktop and Games is a commercial enterprise like Qt so if Treebard makes me rich (that was a joke), I'd have to pay a fee to use Ultralight. It uses C++ for the code but for the widgets it uses HTML5. From what little I know, this should work faster than a website made in Javascript and way faster than a Python web app. If I'm not mistaken, Ultralight is for making standalone apps like Treebard, not web apps like the various genealogy websites where you create a family tree on someone's website.

When it comes right down to it, I could make a web app with Sqlite and Javascript (if I'm not mistaken) and run it as a standalone (client-side-only) application in a browser. I hope to not have to do that but it would be better than having a Python app that is only for looking at. If I'm being honest with myself, the idea of a showcase of functionalities is maybe a wanna-be standing on a soapbox vs. an application that can be used. No matter how good the functionalities, the idea that an application should do serious work in its own field kinda seems too obvious for words.

The dependencies for Ultralight are Git, Cmake and Visual C++ Studio which I'm trying to download right now.

Having been working on a Python app for two years that no one is going to be able to use for large databases, I have no regrets about the time spent but hesitate to spend much more. I love Python but for some applications it's only good for a quick test of an idea, since it's faster and easier to write than a compiled language like C++.

As for why I'm not using Qt like everyone else, it's a commercial enterprise (so is Ultralight) with a free license for non-commercial or open source use, so theoretically I could use it. But last time I tried to install it and had a problem, when I tried to send a message to Qt they refused to accept an email from me because it's @gmail.com (not a business email address.) So they're too big for their britches as my Mama used to say, and they're too big for me. I tried looking at their so-called forum but the page with topics had a huge Qt logo plastered onto every topic and there was no organization by category, only search. Like Facebook groups. Useless and search turned up nothing to help so forget Qt, it's not for me. I like the open source attitude, the projects tend to be underdocumented but the users help each other out. Qt's pretense at openness by having a free license doesn't work if the program doesn't work because it doesn't create the kind of open source community that an open source project of its size would have.

If Ultralight's user community should turn out to be similarly useless then it looks like I'll be learning node.js, I hear it's faster than plain Javascript. I wouldn't mind writing a program that works in a browser, doesn't connect to the internet, uses Sqlite, html, CSS and plain Javascript or Node.js. It would be fun and if a lot faster than Python it might even be useful to someone with a big database.

Anyway I'm just killing time while Visual C++ downloads.

[Uncle Buddy]

As I continue brainstorming and researching, I see no indication that Ultralight is well documented. Try googling Ultralight UI and sqlite. Nothing. Look for the Ultralight forum. This is reminding me of my impression of QT. So here's how it looks in my current state of discouragement and not enough sleep: commercial software like Ultralight and Qt try to appeal to open source types but there is no support worth mentioning if you don't buy a license, and that includes user groups which seem to barely exist. No Q&A re: Ultralight on stackoverflow is a bad sign.

Open source projects, on the other hand, have better support... if they're popular... because users help each other, but to qualify as a part of this community there are prerequisites. The way it works sometimes is that by the time you have enough knowledge to ask the right question, you've figured it out for yourself. My having no formal education in computer programming is not going to change.

Fiddling around on Python is a nice hobby, I like it, it's fun, it's still fun to do if no one is benefited but me.

At this point I think I have two choices: stick with Python and enjoy my little hobby for my own reasons or learn how to build programs that don't come with one-click Windows installers. I think the latter should be my next topic of research. I'm still going to try Ultralight, at least the samples, if I can get all three dependencies to work.

[Uncle Buddy]

I got the pre-written Hello World program to display, so the Ultralight program does work, but the samples did not load (unless "samples" refers to a single Hello World program?) and there's no way to ask questions as far as I know. Looks like the user group is Slack, so maybe I should look into it. An announcement is pleased to announce "new docs" but this just goes in a circle back to the page that mentions "samples" which don't seem to exist. Unless I find that Ultralight-ux or Ultralight UI or whatever it's called is easy to use with Sqlite...

I just tried to join the Slack group but it's requiring me to send a message to the group, add a picture, download an app, and three other things before I can see the group content. I just want to browse the content and search for the term "sqlite", I don't want to propose marriage to a stranger, know what I mean?

Looks like it's Python-Sqlite-Tkinter for me, a combination which I happen to love and appreciate all the more, having searched for two days for a way to replace it with something that runs a big database fast.

[Uncle Buddy]

The next episode in the horror story is PyPy. The reason I'm using Python to begin with is that it comes "batteries included". Not every possible battery. I had to install a module called Pillow in order to use graphics other than .gif. But generic Python, which is also called CPython, comes with Sqlite and Tkinter so I've only had to install Pillow so far. Hoping to keep it that way.

PyPy is another kind of Python that runs a lot faster than CPython. I tried to install it, got it to work, got it to work with Tkinter, but wasted a day trying to install Pillow.

If I ever try this again, someone please remind me to use virtual environments for my different Python installations. If I had put PyPy and its required partner CPython (version 3.6) in one virtualenv and the CPython I've been using to develop Treebard (v. 3.8) in two different virtualenvs, they would be unable to see each other, like running them on two different computers. Instead I got confusion and conflicts. Making one version work broke the other, etc.

Unlike CPython,the PyPy project doesn't have abundant answers available all over the internet, it's not batteries included. Compared to Python I wouldn't go near PyPy if you were like me, a totally uneducated newbie with no clue how to solve technical problems regarding installing/building/troubleshooting programs and making them work.

The philosophy of the Treebard GPS project is to demonstrate functionalities with code that beginners can work on. Speed is not an issue because Treebard GPS will never have a Version 1, 2, 3 etc. which are backwardsly compatible with each other. If there were such a thing, it would be a different project than GPS. GPS is not for daily use as such, it is to show the best user experience that I can come up with. Except for speed.

If PyPy ever catches up with Python's "batteries included" philosophy, I might try again. It could happen, but what's more likely to happen is that the Next Thing will come along and Python will eventually die of natural causes. Till then I hope to create a project that will be useful for avid genealogists who are not professional programmers and for genieware developers looking for ideas. "Raise the bar" ideas when it comes to user experience, and useful/convenient/easy-to-use manipulations of genealogy data.

Treebard GPS could be used by anyone but because it will not be backwardly compatible, I can't recommend it. Not that it's usable for anything at this point, it's too early. Other reasons it isn't really designed for daily use for most people is that it doesn't have any way to import or export data at this point--that's the last part I'll tackle--and if the database gets too big it will bog down since it's Python. (The only speed issue I'm having with my currently small database is the way it displays images while you're scrolling. The image smears across the screen while you're scrolling since it isn't redrawn fast enough by CPython.)

This notion of finding a substitute for CPython to use for Versions 0 to infinity-and-beyond has been a frustrating interruption to my fun hobby, but maybe I needed a break from writing code 12 hours a day. I know, I should get a life, but I'm one of those people who tends to be overly focused on one thing.

To hopefully conclude this thread for now, let me just say that Treebard GPS so far is awesome. It looks good and works great. There's a lot of features still to add before it can be used to do any genealogy. I'm going to post some screenshots in another thread.

[Uncle Buddy]

It looks to me like the most likely direction to go in for creating a Treebard verson 1.0 would be a newer language like Rust or Go/Golang. These languages might soon replace more established languages like C++. Reading the instructions for installing Go and a GUI toolkit that works with it (Fyne), the installation looks pretty easy. Go was created to incorporate the simplicity of Python with the capabilities of C++, so it seems like it might be custom-made for me.

It's too early for me to start working on the post-GPS version of Treebard but not too early to look into the possibilities.

I think that Python's "batteries included" philosophy is going to have an impact on future programming languages. Python is extremely popular for a reason. Oddly enough, people think software should work, and Python "just works" as they say. Hopefully the notion that one must fiddle around with programs to get them to work right is on the way out. Maybe there will come a day when a program that can't be installed with one click will be considered unfinished. I hope I live long enough to see that day. I'm not begging for effortlessness. But programs should work, including installation programs.

And yes, I should try to learn how to build programs from source but I'm kinda super busy right now writing Treebard GPS while preparing to home-school our son while paying tuition at some school so he'll get a diploma from my efforts... covid, you know, has the world chasing its tail right now. May things not continue to get weirder, but I'm not holding my breath.

[Uncle Buddy]

I tried to install Fyne as it appears to be the most popular of the GUI toolkits made for Go. Unfortunately it has some dependencies including a C compiler which the Fyne developers haven't had time to package into Fyne yet. When they find the time I'll try it out but at this point my non-Intel (i.e. substandard) 32-bit processor coupled with a flaky internet connection are making it more trouble than it's worth to get Fyne to work.

I was told that there is no such thing as a Go GUI maker that is completely free of dependencies but this is not true. I found one. It's called Gio and it's available at GioUI.org. It's open source and portable and it's written in 100% pure Go. Also it's immediate mode, that's maybe the latest thing in GUI programming and I don't know much about it, but it sounds awesome. Gio is not up to version 1.0 yet but its developer is working full time on it and looks like there's a good team. There are some inspiring talks on you tube by Gio's creator Elias Naur.

The good news is that this talk of "no dependencies" is not just talk. Without installing anything but Go (which was easy and worked right the first time), I am able to run, build and edit Gio's example source files. I mean in simple ways; I haven't done my first tutorial on Go yet. The point is that I was easily able to prove Gio's claim of having no dependencies, and that's a tremendous step forward for Treebard since I'd like to get started on Version 0 while I continue to peck away at the demo version Treebard GPS.

Knowing me I'll dive right into Version 0 as soon as I finish my first go tutorial. That would mean a slowdown on GPS but if you knew how close I was to not being able to see well enough to do this stuff at all, you might agree that trying to make a good start on both GPS and v. 0 might be more important than trying to finish either one of them. I believe as founder of Treebard it's more important for me to make a good start than to pretend I can finish. It's unfortunate but what the heck, blind people can still play the guitar.

In the meantime, as long as I can see the letters on the screen and able to sit upright in a chair, I am creating Treebard.

[Uncle Buddy]

I was on Github for awhile but it's overkill for a one-man team at this point. I'll be posting examples of the code here on this forum and making accessory code, updated versions, and a .zip file of the whole project available at my dropbox account for anyone who wants it.

I was enjoying Github but even using the GUI version I forgot how to use it if not using it constantly. Anyway I have my own version control system that works for me.

As of this edit I'm completely gung-ho about the Python version and not worried about the Go version, which I still think might best be widgified in Gio. Or instead of Go/Gio, maybe Dart/Flutter? I'm happy with the Python version for my kind of genealogy and not too worried about version 0 or 1 right now.