today's to-dos
May 9, 2024 17:06:19 GMT -8
Post by Uncle Buddy on May 9, 2024 17:06:19 GMT -8
The new UNIGEDS rules for separation of primary genealogy data storage from app/user/vendor data storage have been very productive at inspiring a large and self-expanding to do list.
from notes:
# The klunky, labor-intensive, fragile, hard-to-understand and maintain, overly ambitious and imperfectly-successful-at-achieving-its-own-goal NOTE TOPIC SYSTEM for making each note ID'd and re-usable has to be abandoned because it doesn't pass the UNIGEDS test: to use it, I'd have to make an exception to UNIGEDS rules or change UNIGEDS rules which I won't do. It also requires the user to create a title for each note which I've never liked. I'd rather let the rules suggest that the note delineation system itself is at fault for its own faults, and change that system to match the standard, which is UNIGEDS. (The actual problem is that the note topic system requires so many database fields to track that the separation of UNIGEDS from GUI becomes too convoluted or impossible to maintain). IDing the notes to make them re-usable is the easy part. Helping the user find the note he wants is what prompted the creation of the note topic system once upon a time. Instead of note topics to help the user find the ID'd re-usable note he wants to link, there should be a SEARCH button which can do a full-text search of all notes and this is also imperfect but has about the same effect as searching for the text in the topic, but there are more things to search for, so more opportunities to find what you're looking for, and less jumble in the notes dialog, less for the user to learn, and a lot of code can be thrown out (including the scariest SQL I've ever had to write), and replaced by a simpler system that works the same for every note. From the notes dialog we can now lose: private, topic, topic_order, table of contents, and the search for existing topics. All this can be replaced by a search button which will display search results at the bottom of the dialog or on a second (modal) dialog so that full note text can be searched and reused.
# new_tree.py has to programmatically add current_tbd and main.tbd to the copy of unigeds.db when the new tree is being created. See UNIGEDS rules vs. Treebard design.
# Go back to getting color schemes from new_tree.py, but put them in tbard.db instead of unigeds.db.
# Get rid of the convoluted code that selects the right name to display according to a hierarchy. The hierarchy has to be hard-coded and stored; it has to be changed when the user adds a name type; it exists only for the selection of one of its items; it will be subject to vendors wanting to give users options to control it; everyone will disagree about how it should be ordered; it is supported by stinky code. Instead, add a radiobutton to the names on the name tab so the user can tell Treebard which name to use as the display name; end of problem. Treebard should just use the first name it finds and let the user change that manually. Make a multi-row vendor table `main_tbd` in unigeds_treebard e.g. "smith_family_tree.tbd".
MAIN_ID MEDIA_LINKS_ID PLACE_NAME_ID NAME_ID
# get rid of `built_in`, `private` and `hidden` fields from sql tables; remove them from queries and remove private from the notes dialog; since unigeds.db types tables are now blank (populated by each vendor according to taste), built-in and hidden types booleans are no longer necessary. Encourage the user to not input private data to a computer program. Treebard is a showcase for (mostly) primary functionalities. Vendors who borrow from Treebard are free to add as many privacy and other worry-wart features as they want.
# redo the main_image procedure so that the thumbnails are pictures on LabelMovable. Get rid of the RadioButton under the thumbnails. To make a thumbnail main image, click it to focus it, then use left arrow till it stops. When the gallery dlg closes, The leftmost image will be saved as main image; in the row of thumbnails, put a blue border around this first one.
from notes:
# The klunky, labor-intensive, fragile, hard-to-understand and maintain, overly ambitious and imperfectly-successful-at-achieving-its-own-goal NOTE TOPIC SYSTEM for making each note ID'd and re-usable has to be abandoned because it doesn't pass the UNIGEDS test: to use it, I'd have to make an exception to UNIGEDS rules or change UNIGEDS rules which I won't do. It also requires the user to create a title for each note which I've never liked. I'd rather let the rules suggest that the note delineation system itself is at fault for its own faults, and change that system to match the standard, which is UNIGEDS. (The actual problem is that the note topic system requires so many database fields to track that the separation of UNIGEDS from GUI becomes too convoluted or impossible to maintain). IDing the notes to make them re-usable is the easy part. Helping the user find the note he wants is what prompted the creation of the note topic system once upon a time. Instead of note topics to help the user find the ID'd re-usable note he wants to link, there should be a SEARCH button which can do a full-text search of all notes and this is also imperfect but has about the same effect as searching for the text in the topic, but there are more things to search for, so more opportunities to find what you're looking for, and less jumble in the notes dialog, less for the user to learn, and a lot of code can be thrown out (including the scariest SQL I've ever had to write), and replaced by a simpler system that works the same for every note. From the notes dialog we can now lose: private, topic, topic_order, table of contents, and the search for existing topics. All this can be replaced by a search button which will display search results at the bottom of the dialog or on a second (modal) dialog so that full note text can be searched and reused.
# new_tree.py has to programmatically add current_tbd and main.tbd to the copy of unigeds.db when the new tree is being created. See UNIGEDS rules vs. Treebard design.
# Go back to getting color schemes from new_tree.py, but put them in tbard.db instead of unigeds.db.
# Get rid of the convoluted code that selects the right name to display according to a hierarchy. The hierarchy has to be hard-coded and stored; it has to be changed when the user adds a name type; it exists only for the selection of one of its items; it will be subject to vendors wanting to give users options to control it; everyone will disagree about how it should be ordered; it is supported by stinky code. Instead, add a radiobutton to the names on the name tab so the user can tell Treebard which name to use as the display name; end of problem. Treebard should just use the first name it finds and let the user change that manually. Make a multi-row vendor table `main_tbd` in unigeds_treebard e.g. "smith_family_tree.tbd".
MAIN_ID MEDIA_LINKS_ID PLACE_NAME_ID NAME_ID
# get rid of `built_in`, `private` and `hidden` fields from sql tables; remove them from queries and remove private from the notes dialog; since unigeds.db types tables are now blank (populated by each vendor according to taste), built-in and hidden types booleans are no longer necessary. Encourage the user to not input private data to a computer program. Treebard is a showcase for (mostly) primary functionalities. Vendors who borrow from Treebard are free to add as many privacy and other worry-wart features as they want.
# redo the main_image procedure so that the thumbnails are pictures on LabelMovable. Get rid of the RadioButton under the thumbnails. To make a thumbnail main image, click it to focus it, then use left arrow till it stops. When the gallery dlg closes, The leftmost image will be saved as main image; in the row of thumbnails, put a blue border around this first one.