This GUI hack monkey patch addon is for Gramps 5.2, 6.0 and 6.1 versions. It needs some field testing.
I am hoping that slide-outDate Calculator will get some layout tweaking suggestions. Since this will be submitted as a core enhancement, the turnaround time for tweaks is measured in years! So let’s field test it early so it will be right when introduced in the 6.2 version. (Or will that be 7.0?)
In version 6.1, @SNoiraud created a nice upgrade to the calendar gramplets with Pull 2209. And kindly extended the enhancement to the Date Selection dialog. This expands the Daily Calendar from the original to include dual calendar selectors: (if not a Span or a Range, the right panel is preset to today())
This new slide-out Date Calculator is useful for those obits and headstone that say: “Aged 87y 6m 5d” but don’t have a birthdate. Just use the date of death and paste in the “Aged 87y 6m 5d” as the offset. It will calculate the “Aged” as a negative offset.
I did not want to wait for 6.1… so this version is tested in 5.2 and 6.0 version. It is a simple 2 GUI file drop-in patch (a new widget and a replacement editor) to the core, with Gramps not running.
Date Calculator slide-out for the Edit Date dialog
Slide-out panel. A narrow triangle tab on the dialog’s right edge (▸ closed, ◂ open) opens the calculator. The window grows by the panel’s width and shrinks back exactly on collapse; while open, resizing changes only the panel.
Reference date. Prefilled from the dialog when the panel opens (unless you typed something). Blank shows the Result hint.
Date or offset. A date, years (5), or years/months/days as -2, 3, 10 or -2y, 3m, 10d. A leading minus subtracts the whole offset.
Result to Date loads the result into the Date fields (a Range or Span keeps its type and second date).
Result to Second Date copies the result into the Second date; the Type becomes Span unless it is already a Range or Span.
Calculate, Copy, Clear. Clear empties all three fields.
Drag and drop. Text (or a drag from a calendar) dropped on the panel, outside a text box, replaces the Reference date. Text boxes take drops as usual.
Errors name the field: Error: invalid Reference date, Error: invalid Date or offset.
Runs on stock 5.2/6.x.markdown_render is optional (built-in fallback).
Discourse does not allow attaching a .py or .zip here. So PM if you would like a copy of the patch files. Or manually download and install the 2 modules in the DateEditorPatch20260928.zip archive found in the Emyoulation GitHub repo .
I think the calculator might need an “evaluate” feature. This could show what Gramps thinks a date approximation means.
e.g., a date approximation of “1944” evaluates to an explicit “from 1 Jan 1944 to 31 Dec 1944”.
Likewise, the modifier such as “about” and “before” qualifiers could evaluate the current Preferences values to show the exact ‘from-to’ span… or maybe that should be a ‘between-and’ range?
because the death happened at a defined date in 1944. If the event is RESI (residence) „1944“ does not mean that the individual lived at a place the whole year (FROM/TO), but at least at one day in 1944.
I’d welcome ideas about how an “evaluate” should be implemented in the GUI.
My initial thoughts were that it should be automatic… simply be a display-only feature that explicitly describe the way Gramps understands and evaluates the “value” of the date string.
But then I wonder if it shouldn’t offer an option to transcribe that “explicit evaluation” overtop the implicit expression. (And how that might be interfaced.)
And where it can be displayed without cluttering the interface even more. Or so that it would not add ambiguation instead of clarity. (Which is what lead me to look at the “Text comment”.)
I have not come up with an acceptable approach. So am stuck in analysis paralysis.
I just did some quick functional tests. The whole Date Selection dialog with Calendar preview needs some major testing. (That is for the already merged PR update … before my slideout complicates the implementation.)
Preferable that testing should occur before 6.1 because fixing the enhancement is also an enhancement, not a bug. So resolving the shortcomings will potentially be pushed YEARS down the line.
A lot of it is not yet functional. Added functions to a version 0.0.1 beta version
any “Text Comment” changes are silently discarded unless the “Text only” is also selected from the Type menu.
although the “Second date” calendar preview defaults to Today(), that value does not populate the Year, Month, Day fields for the Second Date. Not even when a “(between) Range” or “(From) Span” is selected from the “Type” instead of Regular.
Those fields will not populate if you click a selected date on the Preview calendar. (One must click a deselected date and then click back.)
Clicking a Month (or Year) label on the preview calendar will not populate to the Month Year (or year) date. (nor can you Drag’n’drop from those labels.)
it would be nice if a drag’n’drop from the Calendar Preview would populate to the date/second date
the Date and Second Date need a “swap” button
I will ask Claude whether this new Date Selector with preview calendars and slideout can be made into a “monkey patch addon” instead of a hack. That would allow more field testing by a broader audience.
Ok here my two cents worth. Just thinking out loud.
The calculator will be on display only when user asked for it. It closes with one click. So yes the main interface will be (partialy) obscured. But this is the case also with many other windows, plug-ins etc. Rather have the layout slightly bigger and clear then small and obscure.
Since many users might have many different needs. You need to decide if ‘one fits all’ is enough or perhaps that the plug-in can take some preferences that might change the look and result. {Can’t think of examples, but I know users always ask ‘can we do this?’}
Remembering the last x,y screen reference where opened could help users. I have it now covering the bottom half of the screen.
To me seeing the context of a date like FROM 1 jan 1950, resulting in a max of 2000 when the preference says 50 yrs, would be very helpful. Thus indicating It might help entering a date-range. So some sort of infotext perhaps?
It can be distributed as a “monkey patch” addon. And a preliminary version is now available for installation via the Addon Managerfrom the Emyoulation repo.
Most of the changes above have been applied too. See the Changelog
There is a new “Evaluates as:” readout at the bottom of the dialog. When you select “Before Apr 1877”, Gramps looks up what the “Before” mean in the Limits preferences and tells you that that particular Date string means: “Evaluates to: Between 1827-03-31 and 1877-03-31”. Meanwhile, the “to April 1877” Date string " Evaluates to: Between 1827-04-30 and 1877-04-30"
That “evaluation” readout takes the guesswork out of Date Strings.
If you installed the Hack to have the new Date Selector before it releases in 6.1 , you need to reverse the hack first.
So restore the gramps/gui/editors/editdate.py from your original Gramps version and then delete the gramps/gui/widgets/datecalculator.py.
I just appended an “Evaluates to:” below the “Text comment:” which shows the original string.
Highlight and copy is supported for that readout.
Pasted it into the “Text comment” and clicked OK to use that evaluation. The next time (after changing the Date display to “Day Mon Year”) showed it as:
Yes, that’s very helpful to me. Reminding me of the difference in meaning between
Before 1756-09-25 and Before 1756
The editor Makes it clear in one go.
Thanks very much for that feedback. It is very welcome.
The lack of comment for most of the Addons that have been shared has been very disheartening. I have no idea whether anyone has found them interesting or useful.
There’s been discussion here and from some of the International community for some of the new Fuzzy (phonetic) matching rules and LocalTerm (localized Gramps terminology). Which is very gratifying.
Most most of the rest just vanishes without comments. A comment here or there can reshape a mere curiosity into some truly useful.
There are so many addons that I forget about them after I install them. I just now added your Environment Inspector to my dashboard and see that the Gramps Constants tab will be very useful. I also added the Relationship Filter (which you and @dsblank adopted) to the People category sidebar, and I know I’ll be using it often. Previously I had sometimes tried to find people using the sidebar Filter in the Families view but I can see this one will be much more effective. No particular need yet for your other ones (fuzzy matching, eetc.) but I’ll try to remember they are there.
I’ve had a similar problem. Been mulling ideas about a “Installation Punchlist” feature. It might be make exploration more deliberate. Something that will let you do a ‘walk through’ of the batch of addons that were just installed/updated.
Perhaps it would help to keep a Rating system or a review note/PostIt.
But I think that the Addons-source repo increments to a new version whenever any translation is tweaked. (And with 40-some supported languages, that has to be in constant churn.) That defeats my ability to keep track of what’s new.
The experimental Plugin Manager plus (in the “Markdown Based” bundle) already lets you flip through the README.md files as you scroll through the plug-in list. I suppose it could be modified to flip through “CHANGELOG.md” files as another option and sort newest first. That would be a start… but still does not fully satisfy the need.
The “Text comment” field was originally designed to NOT be connected to the date string parser for validation. Instead it bypasses it deliberately.
Apparently, this was to allow users to force a “text only” string when the parser was making mistakes. (Something that is a rare occurence.)
To give more feedback about that logic, the “Type” changes to “Text only” when the Text comment is edited manually.
That makes some (twisted) sense. Except that this string is passed back through the parser when this dialog is closed. Then that the “text only” designation is lost. And you cannot get it back.
I am of two minds about what is the correct resolution.
Re-parsing the “Text Comment” is only correct most of the time. So what do we do to support the (rare) cases of apparently parsable date strings that are mishandled?
Your example “van 2001-1-1 tot 3000” string is another special case of interest.
That will parse and validate for you since are in the matching locale. But for English locale, the parser will not recognize “van” or “tot”.
And rarely, it may be desireable to retain the original language.
As an example, assume that you have disproven a “fact” submitted. And the reason it was wrong was due to a translation error. Logging the original (AND the resultant mistranslation) as “disproven” would save you from the work of disproving it again.
Or you might want the original language to appear as a research aid. Most reference documents are going to be in the local language. If you are not fluent in that language, then it can be helpful to see the date in its native tongue. (Also, for 1st generation immigrants to the USA, it was not uncommon for gravestones to be inscribed in the descendants native language.)
But the more likely case is that translating is desireable. (FamilySearch has an international userbase. Even though it recognizes the entry as a “standard date”, it does NOT display those dates in English when that is the UI locale. That has caused some consternation when they are recording events is a language different to the reference materials and locality of the ancestor.)
I think that the connection to the string parser is a valid choice. It prevents the user from needing to type in the date again.
Keeping test remark open for typing however should give the user the ‘expected’ result. Which not a ‘not evaluated’ in my opinion. When it is in actual fact not ‘meant’ to be editable. If that is the case the user should only be allowed the edit its contents by using the calendat function above.
The van … tot construction is correctly translated coming through the string parser. The error I showed you only exists after I had changed the text remark by hand. See the enclosed example where the ‘omstreeks’ is correctly handled, coming from the parser (and NOT entered manualy)
