I’m baffled by a few things on the Clipboard. But the big question is:
Why were the “Ref” objects built into the Clipboard?
When you drag some items from Object Editors to the Clipboard, they show as Ref items rather than the normal items dragged from a Category view. And they have a chain of 3 links as the icon.
The clipboard contextual pop-up menus only appear for Category-level objects and you cannot drop a Ref item into a dialog where it expected a Category-level object. But Category-level objects CAN be dropped in spots that would cause a Ref object in the clipboard.
So it seemed like it was just an oversight where Gramps should have promoted the Ref objects to normal Category-level objects, right? No, it seems that is wrong.
I had decided to play with the code and see if I could figure out how to promote the “Ref” items to regular objects. And I discovered that there were section specifically to create each variant of Ref item.
So now I wonder… what is the functionality that I am not recognizing? The icon implies it is related to ‘linking’.
Maybe an Event ref includes the Role?
No, that can’t be right. The Role is demoted to Unknown as a new ‘Sharing’ is created from the clipboard.
A Person dragged to the Clipboard from the children tab of a Family carries relationship to parent info in the “Title”. Maybe it overrides the obligatory “Child Reference Editor” dialog?
It does, but that is illogical. That would mean there was a duplicate Family since that is the only way the same relationships would exist.
A couple niggling complaints are that:
- the data in columns is organized inconsistently between objects.
only some objects have the ID in the “Title” column
- the headers are labeled ambiguously.
shouldn’t “Type, Title, Value, Family Tree” be “Category, ID, Description, Family Tree”? And extra “Date” column
Gramps 5.1.3-2 on Win10 Home
1 Like
One area that these “Ref” objects are handy are in places. If you are editing multiple place records with the same Enclosed by structure (with dates) then these places by date can be easily dragged from the clipboard into the next record.
That is a subtle difference. And a bit hard to understand for user who are not exceedingly well versed in Place hierarchies and the intricacies of setting up Gramps to reflect changing political boundaries.
So … these Object Editors have an extra Reference Information section at the top. Some have several tabs. Some (like enclosing Places) only have a single General tab.
The settings in the “Shared Information” section is propagated across all instances where that object is used. But oddities in single instances can be noted using the “Reference information”. And this instanced Reference information cannot be shared via the ‘Share’ selection dialogs… only by clipboarding.
So, let’s discuss the subtleties of a sharing situation that has been discussed repeatedly: multiple birth Events.
You can share a Birth Event between twins where they share the same date. (You can also use a date span if the labor went beyond midnight.)
But you must update the Unknown “Role” to Primary manually if you share via the Clipboard… regardless of whether using a clipboarded “Event ref” from a Person Editor or a object-level Event from a view. However, Gramps still defaults to a Primary Role then shared via the “Share selected Event” icon in the People Editor.
If you use the “Event ref” to share the Birth between the twins, it will be a mistake. Yes, the Roles allow different values not matter how the Event is shared. But if you shared using an object-level Event, you can can have different Notes and Attributes in the Reference information for each twin. (You could add an attribute with the different times for the births or different birth certificate numbers.) But if the Birth was shared with an Event ref, then the Notes and Attributes will remain inextricably synchronized. You won’t be able to change one twin’s notes without changing the other.
And this leads to asking the questions:
- it this ‘instanced’ reference information ever actually shown in Reports?
- can you filter based on instancing?
- Are there other examples of where (like the Role) the instance linking is partial
When sharing an Event as a Reference from another person’s event list, yes, any attached Notes or Attributes (in the Reference section) will also carry over to the second person’s event list. But new information can be set (Role, Notes, Attributes) for this shared event that does NOT affect the original person’s event references. A different note can be added to the second person’s reference section. Obviously, any note itself as its own object cannot be altered for one event without also being used for another shared event. The Role and any Attribute are not their own objects so are not shared like a note is shared.
Once a referenced object is shared, it becomes its own unique referenced object.
You cannot share a referenced Place record as a place for an event because a place in an event has no reference context.
The only Reference information that can be searched is the Role of an event. And this is done from the person filters because the role belongs to the person, not to the event record itself.
I did tests after Sharing a Birth Event ref and an enclosing Place ref. Changes to one instance (except the Role) cascaded to the other. It does NOT appear to make a copy of the data, it references a single Ref for both.
Yet the Association Person Ref and the Gallery Media Ref DID completely separate.
I don’t understand yet how it can keep the Role independent while keeping the Notes and Attributes sync’d. Maybe it is some sort of session caching causing an illusion.
Or a programming functionality. When you share an event between two people (or from clipboard to a person or a family) using drag and drop, the role is reset to unknown, but if you select this event from the list of existing events, the primary role is automatically assigned to this person-event relationship
Oh, I understand it as a series of programmatic operations if inheritance grouping didn’t apply. It’d be fairly simple to insert same the internal handles for each child object shown in various tabs of the Object Editor’s Reference Information panel…
What I don’t understand is if this creates a new class of grouped sharing references… where 2 tabs of the Reference Information collect of objects are synched while the General tab contents remain independent? (Because I added a Note to the empty Notes tab of one Object’s Reference Information & it appeared in there other person’s Event.)
That seems overly complicated.
But then I discovered that sharing some Refs create a sync but others do not! There are SO many combinations to test that I will have to create a testing grid document!