a possible language for Treebard version 0 or 1

[Uncle Buddy]

I don't present a supposed version 0 or 1 because Treebard code is a long way from caring about backward compatibility. I prefer to think of Treebard as a model for genealogists who want to write their own app and don't know where to start.

There's always the possibility that someone, maybe even myself, would want to model the Python/Tkinter/SQLite app that is Treebard, by translating it into a compiled language. There are jillions of those, and probably all of them run faster than Python which is not a compiled language so it runs slower. There's no practical problem with small family trees but even with loading my new faster-than-ever recolorizing app, you have to see some flashing as the widgets are formed, or some smearing if you drag a page with images on it. I don't consider these practical problems but in a commercial app, I assume they would be undesirable. So a compiled language is more desirable than Python. If you were devoted to using Python, I'd suggest looking into DearPyGui vs. Tkinter but try them both. I've already played around with DearPyGui in my Linux virtual machine and got instant results, it seems very easy to use, in spite of my experience with Linux being counted in hours or minutes.

As for compiled languages, I've played around with Go, Julia, and C++. Last time I checked, there were only one or two widget toolkits available for Go (mainly Fyne, which I couldn't install on the 32-bit machine I had back then), none available for Julia, and those that work with C++ would have required me to learn more programming than I had time to do.

Now, thanks to a hint from Louis Kessler (lkessler ) of beholdgenealogy.com, I have learned of a programming language called Delphi which is unlike any other programming language as far as I know.

Julia had promised to get rid of the two-language problem, where the developer designs a program in Python because developing and testing is so much quicker, and then has to translate the Python into another language. Julia is a compiled language but it's supposed to be very easy to get up and running with it, due to a more intuitive syntax like Python's. But it's a fairly new language and there was no widget toolkit for it. Python's "batteries included" attitude has caused them to include Tkinter and most of SQLite in the Python installation for Windows users, which helps novice programmers get right to work with the creation process by eliminating most of the dependency search-and-install (without any instructions that make sense to beginners), which is so discouraging for impatient people like me who don't want the equivalent of a masters degree in programming in order to start creating a stand-alone app.

Delphi seems to be just what the doctor ordered.

For the past several days, I've been watching with utter fascination this Delphi tutorial on YouTube: www.youtube.com/playlist?list=PLxAS51iVMjv_Y6gmE2DIkUCmDKOcwjHI8. The tutorial author is a high school teacher so the teaching is at a level of mental ability that I can resonate with, although to be perfectly honest, since I have five years of experience with Tkinter and Python, it could be sped up a bit. That's better than going too fast and leaving stuff out. The tutorial is relatively recent and the first one I've found that starts at the beginning. The same channel has older tutorials about using databases with Delphi, and you can use SQLite, though I haven't got that far in my study of Delphi yet.

The Python criteria "batteries included" seems to apply even more to Delphi than it does to Python. The other Delphi tutorials I started to watch almost scared me away, because they started off dragging-and-dropping everything, which made it look beginnerish. Mr. Long's tutorial, linked above, correctly starts off showing you how to type the code also, and how the code and the GUI interact. The great thing about Delphi for beginners might be that it seems to have been created with the dedicated singular purpose of creating a stand-alone app. This is not like how Python eventually got around to adapting tcl/TK as Tkinter with Python installations [other complaints omitted]. Delphi is a compiled language with its own GUI toolkit built right into it. I don't yet know what its capabilities and limits are, but I get the impression that this is going to be a real game changer when it comes to getting non-programmer genealogists started quickly writing their own applications.

I don't mean to suggest it is ever easy to start writing a complex app out of thin air. But for me, having sweated blood full-time under the Python/Tkinter shelter (doghouse?) for over 5-1/2 years, it makes me want to try it out ASAP. Delphi is a complete package (IDE or Integrated Development Environment): code editor, GUI display, and compiler, all purposefully built into a program dedicated to creating graphical user interfaces. You install Delphi and start working. That's not like installing some compiled program because people say it's great, and then wasting weeks looking for a GUI toolkit only to decide that the hardest, most technical part has been left for you to do: setting it up to use when you've never used it before. Delphi doesn't seem to be like that at all.

I'm guessing that it might be Delphi, a mature and stable product--not the new kid on the block Julia--which solves the two-language problem for genealogists who want to write genieware without any programming background. I've also spent a lot of time playing with Electron, but that approach had two flaws: 1) it's based on Chromium which makes it (1a) bloatware and (1b) monoculture, and 2) using Electron is getting harder as the product matures, not easier. That's a bad sign.

Here's a possible Delphi project related to my goal of getting more genealogists to try writing their own apps. (Theoretically, more designers competing could raise the bar for accuracy in designing the primary features?) My theoretically universal data structure UNIGEDS is so-far used by only one genieware project, Treebard. Rather than jumping into translating Treebard from Python into Delphi, I would start over from scratch and write a very different GUI in Delphi with UNIGEDS as its back-end. I love Treebard's design, but I never want to give the impression that UNIGEDS will only work with GUIs that I design. The whole purpose of calling it UNIGEDS instead of "Treebard's database" is to get across the admittedly utopian notion that all genieware developers of the future could literally set out to make their programs better-designed than GEDCOM by adopting a common data structure for their back-end. Getting GEDCOM back on the back burner in regards to design decisions. As for the genieware programs of today, possibly they are going to become the programs of the past if they keep pretending that GEDCOM is going to get the job done (right).

Get the job done. Get the job done right. Two different things.

Another possible use for Delphi in regards to my stated goal would be to create a genieware app for small screens (stupidphones, I call them). Since I am not a fan of smartphones (especially what they're doing to our children), writing Delphi for Android and iOS could be someone else's job. As usual, Treebard and UNIGEDS are in the public domain, so anyone who wants to borrow them can use the code or adapt the code or translate the code in any way they want for any purpose they want.

I could conceivably create something great and then waste the rest of my life trying to control how people use it, but even if I somehow managed to control the result of others' supposed "theft" or "misappropriation" of my work, you can't take it with you. So as a sort of revolt against my own controllish nature, I refuse to get involved with how anyone adapts my work. SQLite is similarly unlicensed, and I don't hear any complaints about that.

[Uncle Buddy]

And then there's Python for Delphi as well as Delphi for Python. I might have more to say about these topics if the study material holds my interest. Obviously there would have to be an advantage over straight Python or straight Delphi.

www.youtube.com/watch?v=m0r80fxZWPI

The first Treebard .exe should become available within the week, maybe today. I can't get over how Delphi has a built-in .exe creation going on all the time. It makes your .exe automatically. In my current quandary over various issues related to pyinstaller (one of the Python .exe creators), this feature of Delphi makes it very attractive.

Not that pyinstaller's .exe doesn't work. It does. I've already uploaded it to Dropbox. What's hanging me up is the related video on how I made it, specifically how to use it, more specifically: the file and folder created by pyinstaller have to stay together as siblings, but can be moved around on the computer. I find this mystifying because I learned this only yesterday, by accident. Previous to that, I got in all kinds of trouble by moving pyinstaller-created stuff without moving the rest of the app (the files created by me). I'm trying to pin down what actually can and can't be done in this regard so my video will be accurate. To complicate things, when you create a shortcut to the .exe, it will follow Windows' rules, whatever those might be. So far it seems you can move the shortcut anywhere you want, now I see I have to test whether you can move the app (will the shortcut be updated by Windows?) So many questions, so little time.

As my Papa used to say, "If in doubt, read the instructions." I might have to try that, sooner or later. I avoid instructions since they tend to be written by people who either 1) know the answer so well that they are blind to what the question might be, or 2) don't know nothing.

[Uncle Buddy]

Here's an 11-year-old video on using SQLite with Delphi's 2 flavors VCL or FMX (aka Firemonkey). I think that VCL is primarily for Windows and FMX works with all platforms including Windows. Delphi uses native OS widgets so a Windows app will look like Windows, etc. VCL and FMX are both Delphi but are not compatible with each other, I guess you'd use one or the other.

Delphi so far seems to be very GUI-oriented, I don't mean the drag-and-drop nature of using it, I mean its purpose for existing seems to be to create standalone apps. This is what attracts me to it, and the fact that it's compiled (so Delphi apps run fast compared to Python); not the drag-and-drop or the native widgets. The latter sound more like obstacles to me but I believe you can also create your own widgets in Delphi if you don't want to be limited by how Windows looks. And since it's kinda verbose, I guess the drag-and-drop and wizards and stuff become interesting too. But very foreign to my way of thinking, I mean back when I was deeply infatuated with learning AutoCAD, I couldn't stand the icon-clicking and only wanted to type all the commands. My mouse hand has ached so long I've kinda just gotten used to it.

Using SQLite, same story, I like typing my code, and I didn't find anything intuitive about using a GUI to write SQL. But Delphi is attracting me.

I will also be looking into whisperings that Delphi is old or worn out, though the same is said of Tkinter and I find that to be rubbish. There is a lot to be said for mature products vs. always going for the latest thing, and looking modern is the least of my concerns for a genealogy program. However, I'm sure that Delphi is updated much better and more often than Tkinter, which is supposedly going to be dropped from Python someday. (Don't hold your breath for that to actually happen.)

www.youtube.com/watch?v=416qL6is5Xw

[lkessler]

Well, I like Delphi. It is really Pascal with extensions that make it an extendible object oriented language. The IDE allow you drop Windows objects onto a form, change it's properties, and execute code for various events, e.g. mouse-click, selection, etc. It really can do anything and similar to Python, for anything it can't do there are 3rd party packages available that can do it.

Embarcardero continues to develop it and they come out with a new version with bug fixes and enhancements almost every year. If you prefer C++ to Pascal, Embarcadero also has C++ Builder that uses the same IDE and has the same basic workings as Delphi.

But Delphi is not free. There is a free cut down Community Version with a limited Commercial License that you can download to try it out. Most 3rd party packages are not free.

Delphi and C++ Builder's main competition is Visual Studio.

[Uncle Buddy]

I don't mind that Delphi is not free, if you're making less than $5000 per year from it, as it will be a fairly nippy day in hell before I find myself making over $500 a year from my project. I've set up a system of donations so people can contribute to my wife and child here in the Philippines if they keep the website online after I'm gone. I hope to last another 30 years or so, depending. But for anyone's information, current donations while I'm still alive are also going to my wife and child. I don't bother with marketing as I have no talent for it and I believe if I make something good, it will attract whoever it's supposed to attract.

I think Delphi is pretty awesome, so far.