Thanks this was helpful, it looks like they (probably?) are using the file saving option based on this code:
My only concern would be that my gramplet would presumably have many more files for templates. However, I realized with your mention of the SuperTool Script that people may want the option, regardless, to share individual template files for use by others. I think the directory file option also makes this easier, however I could theoretically include an import / export function to allow sharing of templates even if I chose the database route.
As for me any choice is good because I like json/xml. But maybe anybody of users dont understand these formats. So UI with DB saving format would be better for them.
The good thing is there is a UI regardless of which option I go with. I think the question is mainly what format would be preferred by people who may want to use a text editor over the UI. I have tentatively decided to keep the directory file structure for now.
In other news a quick update: The template save, load, and rename functions are almost completely implemented now (the user will be able to rename templates both by double clicking on the selected template name and by clicking the rename button). I just have to implement blank un-editable defaults (so nothing changes for regular forms users when the addon is updated- the user must actually select / create a different template for anything to change) and some sort of a way for the user to actually name the template file they create. I’m trying to figure out how to do so without adding a new popup widget but I am coming up empty so far. The best I have come up with is I can have a default template name that is created when the new button is pressed like Template 1, Template 2, etc. which the user can then change.
Here is my informal roadmap for the next couple weeks:
Next up will be actually connecting the main forms addon to my settings addon so it can create new events. Eventually I’ll probably also try moving the settings to the preferences window instead of the normal gramplet area.
After I’ve worked out the basic event creation part of forms I will then work on the more detailed custom event constructor which will allow single events to be built from multiple form fields and for fields to be mapped to other parts of an event object (like the date, role, etc.) besides the default event description.
I have also been making minor cosmetic improvements here and there. The biggest thing for me in that department right now is I want to figure out how to allow users to adjust the width of all 3 sub-containers via dragging the area between each section with the mouse. I know there is a GTK setting for that, but haven’t run across it as of yet. I also fixed some of the screen reader issues I identified before.
A pretty nice feature with the way I have been building this so far is that nothing needs to be done to add support for new form definitions. The form definition just needs to be in one of the form files and all the gui elements, folder structures, etc. are built on startup so any changes to files translates directly to new forms or updated forms in the interface. Which will definitely make error catching and recovery more complicated but I think it is worth it.
And also one question that concerns me is about updating of existing events instead of create new. For example: person already has Residence event with “Place 1” and “Date 1”. How will it work if:
we are creating Residence with “Place 1” and “Date 2” - extisting Residence date should be changed to date span.
we are creating Residence with “Place 2” and “Date 2” - new Residence should be created.
we are creating Residence with “Place 1” and “Date 1” - no changes expected.
This question is also actual for birth, death and others events. Looks like this is not so easy because of it needs a lot of different conditions for different event types. @RenTheRoot which strategy are you going implement:
add all necessary requested conditions from time to time via build updates in the repo
give ability to users customize conditions under their personal needs
Do not create date span because this is an assumption of continuous
residence the events that create the date are unique only proving
something occurred or someone was on that date in that place.
phil
I think it depends on context if a date span is the correct approach or not.
For example, if census 1 says a person was born in 1900, census 2, 1898 and census 3 1901 then personally I would want one Birth event with a date of “between 1898 and 1901” (and “calc between 1898 and 1901” if the year of birth was calculated from an age in the census)
For a residence event I agree with you that a date span is not what I would want. We just know that on those specific dates the person lived there. In between those dates, anything is possible.
Files have the advantage of being easier to share between trees \ computers \ users. Would you be able to use a single file across all trees on the computer?
Database is just a single location so the data cannot get separated \ lost from the tree. But the data is tree specific (I’m assuming by “database” you mean the main gramps DB)
If you got with the database option, it would be nice to be able to export to a file to then import into a different database.
Agree with you guys. I was in a hurry to combine the residences into a span, which is really not very correct. But it’s probably too late, because I have about 1000 such residences. The only option to fix this is to divide the common residence into several separate ones with a script. All my residences have several Citations. This can be used to separate residences.
Thanks for bringing this up, I hadn’t fully considered this.
I think I plan on doing a combination of all three. The first iteration of the addon will always create new events with the exception of when the transcription itself is edited. In this case the events that had been previously created by the addon will be “refreshed” to the updated information.
This also brings up the interesting question of what will happen if the user switches which template they have assigned to a given transcription. I think this will actually require a new tab in the forms addon itself even though I was trying to avoid this. Maybe I will only show this tab if the user has activated the new updates in the global preferences. This tab would include a combobox with the template options available. Selecting a new one will popup warning saying that doing so will delete the events previously created by the addon for this form and create new ones based on the new template. Maybe I can add new features later on that allow the user to decide whether they want old events to be deleted or not on template changes but for now I think this may be unnecessary.
As far as date ranges go it will be possible to use a date range for an event generated by the form, it will be possible through the advanced custom event builder. However, for now it will not be possible to attach multiple forms to the same event, so ranges across forms would not be possible.
This would be possible with the addon. I will include the ability to include simple calculations in the construction of an event.
On the other hand:
This would not be possible with the addon. However, I would recommend that for censuses instead of tying an event directly to a birth you should instead use an “Alt. Birth” event. This is what I do in my tree. That way if you have a more specific date for a person’s birth it is not overwritten by the census.
As a matter of fact, events such as Birth which only have one potential value present a unique challenge which I will need to decide how to handle. I may make using forms to update these values available only through the advanced event builder interface. Obviously documents such as birth certificates should be able to modify these directly and some documents such as Swedish censuses which often have the full birthdate but most others should probably use alt. birth events.
Another potential consideration is I may allow use of a simple comparison logic in rebuilding birth events. For instance, a user could compare the degree of specificity of an existing date value with the degree of specificity of the new one. If the degree of specificity is higher for the new value the user could specify that the new value should overwrite birth. Similar logic could be employed for situations where the degree of specificity is the same.
There is also the potential of automatically adding todo items if certain conditions are met. For example, if a birth date from a census matches the specificity of the main birth date but has a different value, the program could make an alt birth date and a todo with instructions to investigate the dates further to determine which is more likely.
I keep thinking of more edge cases so I am going to stop here, but thanks for the feedback, I have a lot of important behaviors to think about. I think I will need to break out the flow charts again!
The way the directory tree is setup any templates you make would actually be accessible through any tree you open on your computer.
Actually in this case it would mean creating a single new database which would be accessed by the addon. In this way the database would be tied to the addon and not the tree itself.
Sure, I have made a number of custom forms I can probably spin one up pretty quickly for you from an excel file manually.
Unless of course you are asking if I can add in a feature to automatically turn csv files (maybe xlsx too) into form files, in which case I can probably add this as a feature without much issue.
The current CSV import doesn’t allow creating a separate Event (like a custom Event type that would suit a Ship manifest/crewlist) and then sharing that Event to specific list of Persons and their Role in the Event. Would be nice though.
No, I was just thinking about that one or two (doesn’t remember, need to find them) at the moment, its xlsx files with formatted columns, some of the columns are multi-headers columns, so for those CSV can’t be used.
This is only a design template for common ships manifest and crew list/manifest for ships sailing on US ports.
IF it would be possible for a user to create a xlsx or ods file with a template and import it as a form design, that would be just “WOW”.
Text files are probably the correct approach. In Gramps we tend to use ini files for preference settings. For more complex configuration options you could use either XML or JSON.
Feel free to enhance the format of our existing definition files. You can add extra tags or even change the format in a major way. The update from the Census addon to the Form addon involved running a script to transform the definition files.
Yes I can definitely make a couple manually, I can even probably make a pr to the forms addon with the manifest forms included. You can send them however you would like.
This is definitely one of my goal features. I am not sure if I will add it in for the first release or if I will make it part of a future update.
Another small update- I wound up spending some extra time figuring out how I want some of the rename, save, etc. parts of the settings interface to look / function and I think I have settled on a design. Note that some components, like delete template, are not added yet because I am very excited to get to the event creation programming and am planning to add those later on.
I have decided to include the save and rename as a single option. This has the added benefit of making it extremely easy for users to duplicate their templates with edits. Changing the value in “Template Name” and clicking save does not delete the original template, it just creates a new one with the same settings. Using the same “template name” acts as an overwrite / standard save which updates settings in the template. Users will use the delete button to remove templates they actually don’t want.
This interface decision is meant to minimize the number of buttons and hopefully allow a more intuitive workflow for template management without any popup windows.
Could I ask why you appear to have a drop down box for occupation as this list would certainly be hundreds if not thousands, a simple text entry on that attribute would in my opinion be more than adequate.
A nice added feature might be allowing the addition of notes to forms
phil
