Very often I have events that are part of multiple people lives (say whole family). For example, a Residence event where the whole family moved to another place.
At the moment I:
create the event for one person (say the father)
then move the event to the Collection Clipboard
then I open another person from the family (mother or any child) and drag the Residency event there too
Repeat the last step for all family members (say like 10 children).
Well, the family has moved 6 times in their live. So it is 6 events for 10 children - so repeat for 60 times…
Unfortunately, it seems one can only select and then drag and drag a single event and not multiple.
Just about the same as you. I usually start sourcing the father then mother/wife and then children. Most of the records get attached to the father and when processing the wife, I open the father and drag the record from father to wife. I do the same with the children where they are the same record. I don’t like using the clipboard for this as the description in the clipboard is vague and confuses me. I work in the family view to do this so it is easy to open another family member to drag and drop an event attached to any of them. I use the clipboard mostly to hold Places so they can be dragged into the event.
The experimental CardView addon supports drag’n’drop too. Th Pinned views add power to the process.
Or…
A SuperTool script to add a specified (by hard-coding or with a input dialog) 2ndry object to selected primary object(s) is a simple application for that tool. Shouldn’t need more that a few lines of code.
Instead of using the clipboard for this, I create the event for the first person, then edit the next person and click on the button to share an existing event. When the event list pops up, I double-click on the ID or Last Change column so that the new event is at the top of the list. Maybe more clicking is involved, but for me that’s easier than dragging.
This add-on is far enough along in development that it can be considered early beta. Note all development and most testing to date has been done on Fedora.
and it looks really hugh in terms of feature set, so I am a little bit cautios about really using it. In the end, afaiu gramps is more or less a sophisticated CRUD DB User interface. And a lot can go wrong in terms of data manipulation if software/addon is not totally stable - and if the DB gets damaged which might not be noticed at first, it could go really bad…
It is a huge set of GUI features. Really really, REALLY huge. Tons of Easter Eggs too. And it requires a dramatic mindshift in navigation and preferences management. Like Gramps core, you have to learn to ignore the parts you don’t need.
But, since it does not create new data model, the data is compatible with what the core GUI does.
CardView has a lot of user miles on it. The reason that it hasnt been integrated and released is that that testing pointed towards some things that WOULD need minor data model changes to simplify development. Since the next evolutionary step in the CardView GUI would require a LOT of throwaway work once the data model was changed, he stopped until that is in place.
Yes. I would expect that you’d have to change the form XML to match. Otherwise, adding new data would re-create the old labels AND the Form tool could not re-populate with the stored data after their ‘types’ has been harmonized…
