Simple minds for tricky times
Jun 10, 2024 3:42:45 GMT -8
Post by Uncle Buddy on Jun 10, 2024 3:42:45 GMT -8
In treebard_root_038.py, unigeds.db (formerly known as default_new_tree.db)--the tree's SQL database--now only stores primary genealogy data.
The elements of genealogy existed before genealogy, they are primary. Places, persons, events, sources, assertions, and added notes for whatever doesn't fit in the other categories.
The secondary features of genealogy software are not about the elements of genealogy but rather about the products of genealogy such as import/export, charts, reports, websites, and books.
The former global database appwide.db was converted to a Python dictionary and a tiny global db called tbard.db. These two small databases--one a Python dict and one a SQL db--now store and update data for secondary features, color schemes, preferences and settings, app data such as which trees were opened last, user data, themes, and the like. The global database tbard.db is very small since types were removed from the global db not long ago.
The new unigeds.db is getting serious about showing the way for what a standard of data exchange should look like. UNIGEDS has to be pure and not used for any vendor cruft whatsoever including output such as chart and reports. This includes this vendor "Treebard". Default Treebard app data will all be stored in text files by new code in base.py.
UNIGEDS does not dictate how vendor/user/secondary data is stored, each vendor will do that their way, and unigeds.db will remain purely devoted to primary genealogy data only, its schema modified only by whoever is running the UNIGEDS project, that's me right now. If someone forks the project or otherwise supplants it with something better, the point I'm hoping to see carried forward into that new project is that if vendor/user/secondary data is allowed into the "standard" for data transfer, then that is the point where having a standard for genealogy data transfer between apps becomes unmanageable like it has always been with GEDCOM.
It's impossible to define a practical, consistent, enforcable standard for genealogy software data without limiting that tool to the simple transfer of primary historical data that pre-exists genealogy. Of course it's also impossible to enforce the purity of UNIGEDS. Vendors who use it will either honor that rule or they won't. I am not hoping to be mistaken for the sheriff of genieware forest, I'm just the gnome hiding behind the tree, muttering at passersby: complicated and difficult solutions create more problems than they solve.
The more complex the problem, the harder you have to try to come up with a simple solution. Genealogy ain't rocket science. We don't need complex, scary software.
Today I rewrote the horribly tangled-up redraw.py which had become unmanagable, unreadable, etc. It's always a great joy to do something over that badly needs it. It's been calling to me for a few years: this doesn't have to be complicated.
The elements of genealogy existed before genealogy, they are primary. Places, persons, events, sources, assertions, and added notes for whatever doesn't fit in the other categories.
The secondary features of genealogy software are not about the elements of genealogy but rather about the products of genealogy such as import/export, charts, reports, websites, and books.
The former global database appwide.db was converted to a Python dictionary and a tiny global db called tbard.db. These two small databases--one a Python dict and one a SQL db--now store and update data for secondary features, color schemes, preferences and settings, app data such as which trees were opened last, user data, themes, and the like. The global database tbard.db is very small since types were removed from the global db not long ago.
The new unigeds.db is getting serious about showing the way for what a standard of data exchange should look like. UNIGEDS has to be pure and not used for any vendor cruft whatsoever including output such as chart and reports. This includes this vendor "Treebard". Default Treebard app data will all be stored in text files by new code in base.py.
UNIGEDS does not dictate how vendor/user/secondary data is stored, each vendor will do that their way, and unigeds.db will remain purely devoted to primary genealogy data only, its schema modified only by whoever is running the UNIGEDS project, that's me right now. If someone forks the project or otherwise supplants it with something better, the point I'm hoping to see carried forward into that new project is that if vendor/user/secondary data is allowed into the "standard" for data transfer, then that is the point where having a standard for genealogy data transfer between apps becomes unmanageable like it has always been with GEDCOM.
It's impossible to define a practical, consistent, enforcable standard for genealogy software data without limiting that tool to the simple transfer of primary historical data that pre-exists genealogy. Of course it's also impossible to enforce the purity of UNIGEDS. Vendors who use it will either honor that rule or they won't. I am not hoping to be mistaken for the sheriff of genieware forest, I'm just the gnome hiding behind the tree, muttering at passersby: complicated and difficult solutions create more problems than they solve.
The more complex the problem, the harder you have to try to come up with a simple solution. Genealogy ain't rocket science. We don't need complex, scary software.
Today I rewrote the horribly tangled-up redraw.py which had become unmanagable, unreadable, etc. It's always a great joy to do something over that badly needs it. It's been calling to me for a few years: this doesn't have to be complicated.