When I right-click, e.g., on the citations tab associated with a person, I’d like one of the possible options to be a “Recent” sub-menu. Under that choice, Gramps should offer a list of the last N citations inserted by the user.
There are several feature requests related to making objects “in ‘Recent’ use” become more accessible.
The usual suggestion is to put the Citation on the Clipboard if you intend to be re-using it. Use a Collections Clipboard addon gramplet if you will need the Clipboard to persist between sessions.
Wiki article: How to use the Gramps Clipboard
Thanks for your feedback. In these cases I usually already use the clipboard but the operation of adding a Citation to a Person still requires many clicks. Actually, the proposed functionality would make it much faster.
I like to use the Data Entry gramplet to “rough-in” a family grouping. It allows successive children to use the same places and source. Unfortunately, it is only applies a Source, not a citation under that source. The same is true for the Import Text gramplet – Source, not citation.
I made an experiment to implement this kind of a feature. It is an addon that patches some Gramps internal objects.
For example, it will add most recently used places at the top of the Place selection dialog where they can be selected:
This should work on all selectors.
The addon code is here: gramps/addons/recent-items at master · kkujansuu/gramps · GitHub
What do you think?
This is a “General” type plugin. So finding the feature is not in the GUI of a distinct Tool, Report, Gramplet or view. Instead it adds a new GUI element to all variants of a dialog. In this case, it inserts a “Recent items:” table in all the Object Selector dialogs.
Click on any share icon and the dialog with a Recent items: selector appears. (See glossary term: Shared Objects)
Since there are multiple items in the “recent-items” subdirectory, the easiest way for users to install is to browse to the gramps folder in the top directory in the kkujansuu repository and from the green <> Code button, choose Download ZIP. From the gramps-master.zip
file in your Downloads folder, extract the recent-items to the gramps52/plugins/recent-items
subdirectory of your Gramps User Directory.
The addon adapts to the version of Gramps and my test was with the 5.2.1 release of Gramps.
When selecting from the Recent items
list, the main selector table focus (highlighting and scrolling) follows to the corresponding row.
After a bit of experimentation, some oddities appear.
- The focus for the Find a Record feature (aka: “interactive type-ahead search” or “seek as you type”) becomes a bit muddy with 2 active areas.
- The Citations in the Example.gramps tree did not scroll when the Recent Item was selected.
- The Select Father and Select Mother (from Family Editor) have a gender filter by default. But the Recent items doesn’t respect that filter. It cannot scroll to the hidden gender until you click the “Show All” checkbox.
But it is VERY useful. (Still need to experiment what the row limit is {most recent 6 rows, no scrolling} before the list turns into a scrolling box.)
using the Recent Items experimental plugin creates a recent-items.json
file in the gramps52/plugins/recent-items
folder. There is a separate section (with lists of objects and handles) created for each Tree. So unlike the “Go” menu, the Recent items lists remain persistent across sessions.
@Nick-Hall, how are the Bookmarks and the Go menu items stored? There are at least 2 internal features and 3 addons that store this same kind of data… all in different ways. Seems counterproductive to have 5 formats for the same kind of data. Perhaps you could give some Software Architect direction?
Maybe some synergy could be added with the related features? For instance, if the Recent Items are unpopulated, it could be fed from the Bookmarks items or a Collections clipboard. Or if the Go menu is empty but there are recent-items, the go menu could be populated from the recent-items.
There could be a sudden boost in persistence between working sessions with this addon.
The preliminary file format for the `recent-items.json` file is:
{
"668b6dc7": {
"Family": [
"fa931d2d3b0620420ba1be429d1",
"fa92ee09c0316071e5f671ce325",
"fa92ee26e827fa8ac12ececf6c8",
"fa92ede4dd11082ca01936cf596",
"fa92edc78e05ec2c2c13ab3b55f"
],
"Person": [
"C03KQCWNLOKRTD4C7L",
"914KQCNJ9TMDQMDL81",
"GXZJQC3II1UEICXMDR"
],
"Citation": [
"c140d2508d94e7c8bc4"
],
"Place": [
"d583a5b7ab21971300a"
],
"Event": [
"a5af0eb6b052a6e711d",
null,
"fa92eea7e4f1bea9eec18af9e38"
]
},
"61f41273": {
"Family": [
"fa9326f60776cdc28c494ccb723",
"fa932548235210e48afb0d38410",
"fa931d7a8ec359936b2de06b1c8"
],
"Person": [
"fa934a5200529c17c807b5204f8",
"GXZJQC3II1UEICXMDR"
],
"Citation": [
"c140d2508d94e7c8bc4"
],
"Place": [
null,
"d583a5b7ab21971300a"
],
"Event": [
null,
"a5af0eb6b052a6e711d",
"fa92eea7e4f1bea9eec18af9e38"
]
}
}
gramps52/plugins/RestoreHist/hist_save.ini
uses a similar format. Except that it is a single set and starts with "filename": "668b6dc7",
instead of "668b6dc7": {
Meanwhile, the Collections Clipboard addon gramplet stores the info in named sections of the various View category splitbar *bar.ini
files and are apparently oblivious to which Tree owns the object.
[Collections Clipboard Gramplet]
name=Collections Clipboard Gramplet
height=200
expand=False
detached_width=861
detached_height=300
state=maximized
data[0]=8004952d00000000000000288c06706576656e74948a0690df69a51e7f8c1361356166306562366162643734633364376662944b0074942e
data[1]=Birth
data[2]=Birth of Abbott, Frances
data[3]=668b6dc7
data[4]=Example
data[5]=8004953000000000000000288c096e6f74652d6c696e6b948a065050d523997f8c1362333966656235356531313733663461363939944b0074942e
data[6]=N0010
data[7]=1855-06-25 line 1 fac secunda Junij Baptiza- line 2 tus est Lewi...
data[8]=668b6dc7
data[9]=Example
data[10]=80049522000000000000008c04544558549443157365636f6e64204c6577697320416e646572736f6e9486942e
data[11]=Text
data[12]=second Lewis Anderson
data[13]=668b6dc7
data[14]=Example
help_url=None
navtypes=[]
page=2
If you are interested in seeing what triggers an addition to the “Recent items” collection, here’s a tip…
I opened the recent-items.json
in the Fedora Linux text editor. Gramps added a record every time the Editor app flashed a notice that the saved file had been updated and offered to restore from the update.
Bookmarks are stored in the database.
The Go menu is constructed from entries in the History
objects. These store a list of recently active objects used in view navigation.
What to you actually mean by “Recent Items”? If you want a list of recently modified objects then these are available in the database, but we would probably want to add indexes to improve performance.
Do you want to store the navigation history between sessions?
This experimental code looks good.
Perhaps we could combine the results lists?
In addition to the “Find” button we could have “Recent” and “Bookmarks”. Icons instead of text for these may look better. Clicking “Find” would populate the list with standard filter results or all records if the search box is left empty. Clicking “Recent” would populate the list with recent objects - this could be the default. Clicking “Bookmarks” would populate the list with bookmarked objects.
Having “Recent” as the default would speed up the dialog since it would no longer have to display all objects on opening.
I mean Kari’s experimental addon that modifies the Object Selector and the .json
(a list of the 6 most recently touched handles for each object type in each Tree handle)
It seems reason to pre-populate the empty Go menu (or empty History objects?) When loading/switching trees.
Kari’s list is not limited to recently modified, nor recently active in the view. For instance, a secondary object selected from an object selector doesn’t push into either of those lists… but it will be pushed into Kari’s recent-items.json
list. (And while the Go menu tracks the recently active, unfortunately ‘new’ objects aren’t ever ‘active’.)
6 items is a bit tight for the recent Place and People lists. (Adding the average Family from previous centuries tend to have more than 6 people. And typical set of events exceeds 6 and each event type is likely occur in different but common Places… birth vs baptism vs death vs burial vs marriage vs education vs residence)
It is not so much the “navigation” history that needs to persist. It is the data entry for a dense source is likely to span sessions. And we’ll be citing the same source and typically the same localities.
Can drag’n’drop & the ‘Copy to Clipboard’ keybinding be made to work from the Object Selector dialog? (This might not be possible since Object Selectors are modal dialogs.)
It would make loading a clipboard (to be a pallette of objects) much easier.
The recent-items accelerates data-entry for those who do not plan. But the clipboard allows organized users to work smart.
A neater way to implement this would be to create a new RecentObjects
class accessible from the DisplayState
class.
It would need a methods to add a new object to a list and retrieve an object list, and also methods to load and save the json file. Your json file format looks reasonable.
The class should also monitor the object deleted signals so that deleted objects can be removed from the lists. It could also monitor other signals if required.
We could then use recent objects for other purposes. Perhaps we could also consider using it to populate the “Go” menu?
How how pushing out this as a 5.2 addon for feedback prior to possible 5.3 integration?
That could test the value of the “beta” status for addons. Maybe “Beta” should have a Feedback loop button built into Addon Manager?
I’ll leave that decision up to @kku.
We can continue down the addon route or go directly to an enhancement to the core functionality.
It might be an opportunity to define a workflow for a “beta” addon?
For instance, instead of the help-url pointing to the README.md, it might point to the repository. Where the browser gives access to GitHub’s Issues and PRs communication channels.
Right now, you would expect the help-url
to point to https://github.com/kkujansuu/gramps/blob/master/addons/recent-items/README.md
But if it instead points to
Then there’s access to those GitHub tools.
Or maybe Beta could still point at the README.md but have another link for the Repo. With a feature for updating the plugin from a freshly downloaded GitHub ZIP file. (The Isotammi ZipInstall cannot handle when there is more than 1 addon in the ZIP to install.)
Another inefficiency could be addressed in the Select Object workflow with this addon.
It is often necessary to use the Select Object dialog to check for existence of an object. You click the “Select/Share an existing <object>
” button, drill down through the list (or hierarchy) to discover if the desired object is there.
If it does not exist, you must cancel the Select Object dialog, click the + (Add) button that is next to the Select/Share button, fill in the data, drill down again for the Enclosed By or Source (if it is a Pace or Citation hierarchy).
So perhaps this plug-in could insert an + (Add) button to the right of the Recent Items: header to handle that common situation?
Since the Select Object dialog is a modal dialog, the workflow would probably have to dismiss the Select Object dialog and spawn an Add new object dialog in its stead. To avoid the extra drill-down, perhaps the process could flow in data keyed off of the record that was active in the Select Object dialog. (The same way that the Add button in the category view modes key off of the active record.)
When the Add commits the new object, it is arguable the commit could do any of 3 additional actions:
- do nothing after committing the newly created object
- re-spawn the Select Object dialog with the freshened Recent Items (which will include the newly created object at the top)
- apply newly created object to whichever window spawned the Select Object dialog
Notes:
Active record data pre-fills when adding in hierarchical/grouped Category view modes:
- Add Place Tree: into the Enclosed by
- Add Grouped Person: into surname (including Prefix, Connector, Origin, primary
- Add Citation tree: overlooked opportunity to pre-fill Source
I don’t think I will develop this addon further. It was an experiment to see if this is at all possible. I hope that something like this would be implemented in the core Gramps.
There have also been several enhancement ideas in this discussion but I believe they would be too cumbersome to implement using this kind of an addon.
I did some new source additions today for my research Tree (50k people, 18.5K families, 100k events, 4.25k places) and this addon made the process virtually painless.
Thanks Kari @kku !