Yep, this is simply the settings interface, not the forms interface.
My extension provides an interface through which items that have been transcribed in forms can be automatically used to create events.
So in this example. This is a template that is used to map fields in the forms interface to events. This is not really a drop down selector for occupation- this is a selector for event type. In this case I have specified that when using this template for a form the contents of the column for âoccupationâ will be used to create an event of type âoccupationâ. The drop down allows the selection of any event type from the userâs custom events and default events.
In practice when this template is activated for a form âoccupationâ events will automatically be created based on the userâs transcription. So if in my transcription I put the occupation as âFarmerâ when the form is saved a new occupation event will be created for the person with the description âFarmerâ.
So basically all entry options for the forms are going to stay as âtext entryâ boxes when using the actual forms addon for transcription.
The main conceptual problem I am running into now is the question of how to identify to the program which events were created by a form. I may be missing something obvious here having to do with how the master connected event being edited is tracked by the form addon that could be extended to these extra events since I havenât completed my full code analysis as of yet. However, if I am not missing something these are the ideas I have brainstormed:
First I realize I need to allow for different scenarios that could arise. For example:
The user may attach multiple events of the same type for a person to a single form. Ex.: Swedish censuses include residence information for several years so a user may wish to map multiple columns to individual residence events with specific dates.
I plan to allow multiple columns to be combined in a variety of manners to map them to a single event. For example, in US censuses there are often two columns that could directly map to a single occupation event- these being âOccupationâ and âIndustryâ. A user may want to make an occupation event whose description is âWorked as a {Occupation} in the {Industry} industryâ.
This means that however I link the form to events I will need to be able to then connect said events to the rules from the template that was used to create them. That way any edits to the fields tied to said rules will update associated events on save.
The way I see it the best way to do this may be using either attributes, notes, or both.
My current idea is this:
A private note is attached to each reference of the master event. This note contains links to events that were created by the forms addon using this form for the person.
Events that are linked will then have some private attributes with additional info. Specifically there may be âComponentâ attributes each containing the name of one of the fields used to create the event. This can be used to connect events to their respective template rules.
Problems may arise when I implement the expert template definition interface allowing higher complexity event creation rules to be implemented. In these cases there is a possibility that several events may be created using the same fields but with different contents. So I may decide to add another attribute named something like âTemplate Ruleâ which can contain the name of a custom rule used to create the event so that disambiguation can be performed by the program. In fact, it should be possible to keep the number of attributes added to an event equal to 1 by using a âComponentâ attribute for simple events made only with a single field and using âTemplate Ruleâ for more complex events.
I would be interested to hear anyoneâs thoughts on this approach or if anybody has a method which would be more effective.
Another small update, I now have it set up so that events I connect by hand track the values in the template. When I change the value in the form the value of the attached event changes as well:
Quick Update: I wound up using a different method for event linking (json in an event_ref note) but I now have it setup so that new events are created and updated based on the template.
Its been a while since I updated, I have been doing some cybersecurity competitions and have been a bit preoccupied with my research fellowship. But here is a quick mockup of the advanced template creation interface. It will change pretty substantially. Basically there is a tab for each part of the event and a toolbox with variables and operations that can be dragged into the template area to craft a custom event definition.
I have run into some issues trying to get drag and drop to work. Can anyone suggest a reference in gramps source code that contains a simple implementation of drag and drop? I canât seem to catch the âdrag-beginâ signal for some reason.
The experimental CardView addon views have extensive dragânâdrop capabilities. And they even allow dropping a source onto record to add it without the need to open an Object Editor for that record.
If you havenât tried it, look at his Pinned Views feature. It allows an entire view to be used as a dânâd palette instead of just loading the Clipboard.
Yeah my current hurdle is figuring out how to get the code to work with the ToolPalette widget. I think it will probably take me a while and then click eventually.
Are you planning on a ToolPalette like the built-in NoteEditor or the add-on NoteGramplet Gramplet? Or the record navigation widgets of the built-in To Do or Notes gramplets?
More as a way to drag and drop the different variables onto the constructor grid. It actually works fine I am just being a bit nitpicky. I canât get the toolpalette to let me define an icon for the drag over. I think Iâm going to stop worrying about it and just keep developing for now since it does work.
Hmmm. That sounds similar to the function of the Gramps Plugin Registration that defines the path to a new icon for the View Mode which is then added to the Toolbar and Navigation sidebar.
I think only the the path for that happens in .gpr (and only for View type plugins⌠like CardViews) of the addon. You would have to explore the core for examples of the rest of the puzzle: registration parser, the context portion of the toolbar builder, and the Navigator sidebars.
Its actually even more embarrassingly nitpicky than that. I have the icon working fine on in the toolbar, and it appears fine after being dragged, its just in the process of being dragged there is no icon. There is a function in GTK that should work given toolpalette inherits from widget, it just⌠doesnât.
It is supposed to contextually pickup the indicated object type and overlay the âgrabâ mouse pointer. So it correctly combine a tiny (16x16) icon from the indicated clipboard record ⌠but⌠it mistakenly offsets the mouse pointer by how far your click on the clipboard column is away from the âTypeâ clipboard column. (Height of the click in the row affects the tiny icon vertical offset) Making it difficult to know where the âhotspotâ of the mouse pointer is.
You see below, where Iâve clicked in the Title column and started to drag downwards.
Compared to where the click (and start of dragging) is near the center of the Type column.
There was also an issue and PR where dragging from the Place View to the clipboard dragging a âRowâ instead of an icon. The code change to make it drag an icon might also be enlightening.
