Proximity Collection Clipboard

When fleshing out family records, I often find myself re-selecting from the same small pallette of Record Objects but having to repetitively drill down from the top & through the whole spectrum of Record Objects.

(As an example, the family members often have the same group of 3 or 4 cemeteries. I’m processing from the same few Sources, cross-referencing to the same local newspapers & online databases. The Places they were born tends to be the same townships and had they had residences in the same general area. )

So, I keep tossing Places on the Clipboard (Mostly because the Place Tree has so much latency when populating the Selector and it is so tedious to drill down through.) And it helps… until I close the session and have to pick up the work again later.

It would be nice to have the clipboard palette of objects re-loaded automatically. Have it use a filter of People in proximity to the Active Person/Family (like the Degrees of Separation by @Mattkmmr ) and load a clipboard pallette of all the nearby People, the Places they referenced, and Sources used in that group.

Since you might only notice a selection is getting repetitive after the fact, another option might be to poll the session log and populate from the recently changed records.

Refreshing the pallette shouldn’t be dynamic. It would be good to have a button to force re-polling the pallette.

Or maybe such a feature should be a tool that pushes data to the Clipboard instead of a GUI button? If it was a tool, maybe it could have a histogram-based filter for omitting outliers… ignore objects that are only referenced once is a small selection … or less than half a dozen times as it looks at a larger group of people or recent records.

One further thing… sometimes you need to Refine the Clipboard pallette. Cleaning is easy with the Clear… but the Drill Down of adding is tedious. It would be nice to be able to one-click switch to the last-used mode in the Category View of an Clipboard object and focus on that object. Then I can load a few nearby Objects into my Clipboard pallette. Or, if an Object Editor window is floating, I can drag the nearby object directly into it.

1 Like

I like these ideas. The first thing would be to make the clipboard content reloadable at gramps startup with its previous session content.

For the moment with actual clipboard, when I close the session and i want to reuse clipboard content, I transfer its content in one of the collection clipboards then i transfer these records links back to the regular clipboard when I restart gramps.

1 Like

The Collections Clipboards (CC) will retain their contents between sessions. And you can detach them from their location so that they will float.

The one thing to remember, if you navigate between different databases, the CC will not keep stored Gramps objects. i.e. store a place on the CC in Relationships view sidebar in one database, open another database in the Relations view, the CC will be empty, go back to first database, the CC will also be empty.

Non object entries will be retained between databases. i.e. text, attributes, etc.

2 Likes

That explains something that was not obvious.

My use of Gramps is characterized by constantly switching to the example.gramps tree. (To validate a step-by-step instructions in replies. For screen captures destined for the wiki. For bug report testing. To test my own assumptions.)

I was looking forward to the persistence of data between sessions in the Collections Clipboards. But it seemed to be unreliable. The contents would persistent during testing but not actually needed … during normal use. My tests did not include switching Trees!

When switching between databases, the contents of a Collections Clipboards (CC) will disappear IF they are stored on a view that is visited.

The information on a CC is stored in the ini files stored in the user’s version folder. Files like People_personlistview_sidebar.ini. Any view you visit with the second database will automatically update the view’s ini files and in the process the contents of the CC on that view. The objects from the first database are not in the second and get erased. Then when you return to the first database, the view now sees that nothing is stored in the CC. If when you open another database, and never go to a view with a CC in either sidebar or bottombar, that information will be retained when you return to your main database.

This view visit is why sometimes you would see a CC’s contents disappear while at other times they did not.

Yes. I realized that and left the realization implicit in my message. I should have been explicit. Sorry.

(People have complained I am pedantic. So I try to edit myself. Then get complaints from the same people for not spelling thing out. I don’t seem to be able find that happy medium.)

And I was just trying to make my point clear after my convoluted explanation of what was happening in the background.

But this is also a warning if you periodically do a clean import of your database into a new tree. (I did mine today.) Be careful which view you are on when you create the new database. That view will be the view the new database will access and will clear any CC contents.

2 Likes

that is their problem, not yours!
Write like you want and ignore people that complain.

I have never seen you write anything not understandable… and English is not my first language.

It’s all about willingness to understand or not… some always think half empty, some always think half full.

2 Likes

Well… it’s often been executives at work during our ‘corporate teambuilding exercises’… so I kinda hafta pay some attention :laughing:

Thanks for being supportive!

I finally found an easier way. I have the example database open at the same time, in a completely separate instance of Gramps. (Of course, you could also do that with a virtual machine or a separate physical machine.)

On my Mac (sorry, I don’t know whether/how this would work on Windows or Linux), I just made a copy of the packaged installation. In other words, in the Applications folder, I made a copy of Gramps.app and gave it a different name. Then, within the new copy (right click, Show Package Contents), I edited Contents/Resources/gramps_launcher.py and changed the APPDATA environment variable to point to a different place than the default, so that it doesn’t conflict with my original installation. That means it has its own family trees, custom filters, preference settings, addons, etc.

I can also use the copy for learning by experimenting with the code without endangering my regular environment. And I gave it a different Theme so that it’s easier to tell it apart.

Initially I had spent a couple days trying unsuccessfully to build a separate version from the source code, in an environment that looks something like this, then realized this approach was much simpler.