Some new terminology and some retired terminology
Feb 9, 2023 21:04:11 GMT -8
Post by Uncle Buddy on Feb 9, 2023 21:04:11 GMT -8
Great news: the word "finding" no longer exists in Treebard anywhere. When I started this project I made a mistake which is typical of guys like me who fancy themselves re-inventors of something, and I also renamed some things that kinda already had names. Anyway, every time I had to explain what a "finding" is, it became more obvious that a finding--a row of conclusions in the conclusion table--is an event or an attribute. It didn't start out this way but the terminology started getting weeded out when I wrote the assertions feature, and that weeding out is now complete as far as I know.
This project now has two names because it has two distinct parts. It's a free, public domain, open source project, so genieware developers who have their own ideas about GUI design can use the database structure and adapt their own GUI to that. Until now I've been calling the whole project "Treebard GPS" and that's still sort of the short version but in reality there are two parallel projects going on.
The back end or database structure is now called UNIGEDS which stands for Universal Genealogy Data Structure. It is explicitly meant to replace GEDCOM someday when it is perfected by either you or I or Juanita over there.
The front end or graphical user interface is Treebard GPS, a way of presenting what's in the database and giving users a way of interacting with the data.
UNIGEDS can be adopted by someone who doesn't want to use Python, doesn't want to use Tkinter, likes the Treebard GUI but wants to create his own, etc.
I am currently working to add a family element to UNIGEDS and Treebard both. This came about as a result of making enough progress on a GEDCOM import procedure that I decided I had to do what everyone expects and treat family units as real elements of family history. I have been arguing against this for a long time but I feel myself gradually moving to the other side of the fence. Not because I think we should merge our designs with the bad habits of GEDCOM, but for other reasons which are detailed in the thread I posted last night.
The work outlined above comes as an interruption to a places tab feature which has seen a lot of progress, and I plan to also create a sources tab feature and a few other things before I post the code again. Huge changes have been made, as usual, including a major redesign of the module structure which I'm very pleased with.
In case you've heard of a new toy called "ChatGPT" I found it interesting that Guugle's version of the same thing is going to be called Bard. Now I can stop worrying that people aren't going to know what a bard is. Thanks to the current thirst for more artificial stupidity than we already have, pretty soon everyone on earth will be googling "what does bard mean". I happen to know that the old Welsh version is "bardd" but who cares. For me the use of the word is just kinda pretty sounding, i.e. less data-esque than some genieware names, and since bards were musical storytelling wanderers, the term is supposed to suggest that genealogy is not so much about names and dates and data as it is about people and their lives and their stories.
Back to work.
This project now has two names because it has two distinct parts. It's a free, public domain, open source project, so genieware developers who have their own ideas about GUI design can use the database structure and adapt their own GUI to that. Until now I've been calling the whole project "Treebard GPS" and that's still sort of the short version but in reality there are two parallel projects going on.
The back end or database structure is now called UNIGEDS which stands for Universal Genealogy Data Structure. It is explicitly meant to replace GEDCOM someday when it is perfected by either you or I or Juanita over there.
The front end or graphical user interface is Treebard GPS, a way of presenting what's in the database and giving users a way of interacting with the data.
UNIGEDS can be adopted by someone who doesn't want to use Python, doesn't want to use Tkinter, likes the Treebard GUI but wants to create his own, etc.
I am currently working to add a family element to UNIGEDS and Treebard both. This came about as a result of making enough progress on a GEDCOM import procedure that I decided I had to do what everyone expects and treat family units as real elements of family history. I have been arguing against this for a long time but I feel myself gradually moving to the other side of the fence. Not because I think we should merge our designs with the bad habits of GEDCOM, but for other reasons which are detailed in the thread I posted last night.
The work outlined above comes as an interruption to a places tab feature which has seen a lot of progress, and I plan to also create a sources tab feature and a few other things before I post the code again. Huge changes have been made, as usual, including a major redesign of the module structure which I'm very pleased with.
In case you've heard of a new toy called "ChatGPT" I found it interesting that Guugle's version of the same thing is going to be called Bard. Now I can stop worrying that people aren't going to know what a bard is. Thanks to the current thirst for more artificial stupidity than we already have, pretty soon everyone on earth will be googling "what does bard mean". I happen to know that the old Welsh version is "bardd" but who cares. For me the use of the word is just kinda pretty sounding, i.e. less data-esque than some genieware names, and since bards were musical storytelling wanderers, the term is supposed to suggest that genealogy is not so much about names and dates and data as it is about people and their lives and their stories.
Back to work.