Ok I really really like the idea of this one. I think I would actually be able to add some of the code into my own program to make it fully functional and have a gui that makes sense. Instead of editing actions directly through many windows, actions could be tied to the “custom events” I am working on right now. A user could select the custom event definitions they have made to add to their “palette” of direct on form actions. Users could choose to use actions then without even creating a new template if they so wish. Duplication would be prevented using the system for event linkage that I have already created. Or would it be better to not link events created in this manner? In that case changing the column contents would not change events that were created semi-manually / were not part of the template. I can see arguments for both but I think it does have to be one or the other.
Once I implement the error checking and response into my main changes that will also not be a problem for this addition to the addon. It will benefit from any updates that are pushed to the event editor I made as it will just be another gui based direct attachment to the main underlying code.
This one would actually fit in really easily with my update. I have not mentioned this yet but if you look at the form editor below:
You will see there is a plus button and multiple objects can be added underneath each column. With the custom events the idea was going to be to add a small submenu to the “plus” button when clicked. With this menu the user selects the type of object they wish to add to the form definition. Previously I was just going to include “Event” and “Custom Event” but I could definitely add another option to represent a “Default Value”. (I think that is what the pr is suggesting?)
The behavior of the default value would be- if a form is opened and the column the default value is applied to is blank, then the default value is filled in. Otherwise the value that is in the column is preserved.
Actually another potential solution, which I am not as keen on as the aforementioned “repair tool” due to how much it would change
Would be to reference columns by hashes instead of their actual names. Then any of the changes would not actually matter- the columns would still be referenced via unique hashes and the names would only affect how they are displayed in the editor. This does have one benefit which is that columns would be allowed to have the same name. This does occur in certain swedish forms- but my current solution is just to add the year referenced to the column names and that works out fine. Its possible there are other forms where this would be very helpful though. I don’t think it would be wise to switch this right now, but it could be something to consider in the far future as a more permanent solution.
I definitely don’t think this would be an option until I implement a full in-app form editor so that hashes could be generated programmatically as the form is edited / created.
Also this has now been successfully implemented (for the most part- I need to add a couple more components to the list that is allowed to have subwidgets but the nested dictionary structure representation is working well) And the code is actually readable!
In an early version of the Census gramplet, I provided a tool to update attribute names that we wanted to change. It simply renamed a small list of attributes when they occurred in census forms.
“In an early version of the Census gramplet, I provided a tool to update attribute names that we wanted to change. It simply renamed a small list of attributes when they occurred in census forms.”
That would be a really handy tool even on a cosmetic basis I have two forms I have been using for years where I have typed “schedule” in stead of “Schedule” and it really bugs me with all the rest being correct.
Phil
It has only been since the release of 5.2 with the introduction of the person’s event reference source/citation that have started sharing census events. I like the individual line number citation. Now I can have the family citation on the event and the individual’s line citation in the reference.
Thanks for the reminder about that tool, I have had it on my do not use list for sometime and I cannot remember why, I think I will cautiously give it another try and report back.
General purpose tools to rename attributes should work fine. There is nothing special about the attributes created by a form.
My code checked for the source attached to the attribute so that the change would be restricted to a single census definition. I’ll write something for you if you get stuck.
Set Attribute
Is definitely not appropriate for Custom Forms if I wanted to set a new
Attribute “Alpha” to a value of “Male” and apply to all people or only
males with the surname Smith (by using a custom filter) then fine.
Type Cleanup
Works with one caveat you should probably do one attribute at a time and
then immediately update the custom.xml file to suit as the .xml does not
get automatically updated.
There are some issues with this add-on
1)The pop up window opens with two panes if you expand the window only
the right pane expands correspondingly so leaving Attributes with longer
names not entirely visible in the left hand pane.
2) Sorting of the Attributes whilst possible is not entirely obvious
3) Sorting in the right hand pane is of no use because the leading
element of the description is the (Event ID or others ID’s) this should
be the trailing element if it has to be visible.
4) Once “Rename” is chosen it would appear the screen freezes with no
indication that processing is going on and it is only when it starts
the Add-on again does it become apparent that it had concluded successfully
Type Cleanup Tool
Just found why it might have been on my not to use list
For Census purposes I have two Attributes “Sex” and/or “Gender”
different census
Neither of which appear when I use the Type Cleanup Tool so my question
is, are there protected terms that do no appear in the lists or is there
another explanation.
Second question if these do not appear how many others are not there
will have to slog through the custom.xml to cross check.
phil
Just wanted to relay what the next steps in development for me right now are:
Allow Custom Event definitions to be saved and loaded from files.
Implement the event tools so they actually have code representing their operations attached to them.
Add some logic checkers to make sure that events definitions make sense before they are saved (for instance, if statements with no operations inside, nonsensical combinations of variables and operations)
Figure out a way for the user to define what should happen if the “type” of data in a column does not match the “type” expected by the event definition.
Allow the user to add the custom event definitions to their templates.
After that the meat of the addon will be complete and I can focus on testing, error catching, edge cases, etc. !
Also unrelated, but I made the US Women’s Cyber Team!
I understand that this item is WAY beyond scope. Just want to put it on the maximum Range Scale of the Radar scope.
@Woody is requesting an expansive enhancement to the CSV import that (superficially) seems more appropriate to a Form. Essentially, he wants to formfill from an Excel spreadsheet into a comparable custom form in Gramps.
