My first gramplet - "Historical Context" for gramps 5.2

Originally the idea was that HistContext should use ‘lang’_data_v1_0.txt as the primary data, and merge it with the custom file. That didn’t work on Windows, and I realized that users might want to decide for themselves which primary data file they wanted - so I put it in the options. Still merges with the custom file.
I have been considering having a list of files in the options, and not just one, selected form the drop down. It seems logical, and my only fear is that we get to many datafiles to select from - perhaps more than fits in an options window?
Anyway I would like more feedback on this.

1 Like

I would see the need for a user to select more than one data set. An immigrant ancestor would need data for where they leave and the data for their new home.

So maybe check boxes to select more than one.

2 Likes

Point taken. Will implement it in next release

2 Likes

Have a couple ideas for the V2 data format:

  • Support a string date.
    Where it passes the string through the Gramps date string parser and, if a valid date is found, extract the gregorian start/end year. If invalid, it is handled like the current NULL date. This would allow using a “today” end date for ongoing events. (Currently, it is unclear if a NULL end date is: a single year event that ends in the start year, or; an ongoing event). This would also allow people to mistakenly include a full date or date range without causing the gramplet to choke.

  • support a descriptive initial row. Where the dates are both NULL (or ignored/reserved for future use), the text column is how the file would be listed in an options list and the URL column is a link to a Discourse/Github discussion of the file.

1 Like

The descriptive initial row is a good idea.
The string date, I am not so sure about. Gramps supports different date formats, depending on your setting. What if I enter a date in YYYY-MM-DD format in the file, and a user uses MM-DD-YYYY as a format?
I see your point about “Today” or “Now”, but that needs to be implemented in another way. I think. Perhaps. Maybee. Or?

Gramps can handle that, as long as you are using methods like Date.match()

Just because I don’t understand:
If I write 01-06-1957 in the file, how will gramps know if it is january 6’th or june 1’st?
The file hasn’t got any information about how the date is formatted

Is this the correct reference:
Date.match() [source]

1 Like

In this case, does it make any difference? The gramplet is only interested in the year anyway.

Yes it does, because if gramps is confused it may not be able to deduct the year. I think my point is, that gramps decode the year according to my personal settings, and may choke upon other date formats.
It will be easy for me to get the year from the string, if I am sure that the year is a four digit number, and that that month and date is separated by a - (minus).
Just for your info, I normally type in dates in gramps and everywhere else as an 8 digit number YYYYMMDD - the only sensible format :smile: but I do not rely on users being as smart as me :slightly_smiling_face:

Using only the year for dates limits use of the gramplet. Historical events usually have exact full dates, and I would not like to reduce this precision to just the year, omitting months and days. For example, suppose a person died on July 1, 1900, and an event occurred on July 2 of the same year. If we indicate the event date as just 1900, it would seem that the person witnessed the event because they were alive in 1900. But in fact, that would not be true.

Therefore, the ability to add exact dates would be a significant advantage for the addon.

1 Like

I think, people who will fullfill default_data_v1_0.txt will know which data formats can be successfully parsed. So, you can limit list of supported formats.
Another way is add some personal setting for this to have ability add praferrable data format. Or maybe use some already configured data formats in Gramps settings. Or just inform users that gramplet supports such data formats …

and yes, this job should do core gramps classes/functions if possible.

1 Like

I am struggling with the dates. Cannot find a function, that will parse a string and return a gramps date or NULL if date is invalid.
Could you give me a hint?
Been looking in dates.py, datehandler and date parser

I’ve been using this:

from gramps.gen.datehandler import parser

datestring = "1900-12-01"   # the only sensible format, and also an ISO standard :-)
dt = parser.parse(datestring)
if dt.is_valid():
    print(dt)

Kari

2 Likes

I would agree, but @emyoulation was talking about something more advanced, and if you look in the gramps wiki it mentions a shitload of formats, that gramps supports.

I think you have minimal chance of making generally available add on
limited to that format 1900-12-01
All mine are 01 Dec 1900 or it’s variants
before 01 Dec 1900
after 01 Dec 1900
about 01 Dec 1900
from 01 Dec 1900 to 01 Dec 1901
between 01 Dec 1900 and 01 Dec 1901
For me all have to be looked at
phil

1 Like

And how do you convert that string (01 Dec 1900) to a “standard gramps date”

Seems like the Parser will work with 01 Dec 1900, but it will not handle “today”

Does it handle the translation of “today” in the OS language?

Just unsuccessfully asked Perplexity to identify where the Event object editor validates date string entries and convert it to a date object. It totally punted and described how any Python script could handle “today” with the date.today() method “from datetime import date”

Meanwhile, the gui/editors/editevent uses a monitored widget and calls the MonitoredDate class

and in the set_date() function, the pertinent line seems to be:

Yes because it is one of the available standard formats,
because I use GraphView as my working environment and full dates look to
me ridiculous over the years I have modified various elements
so, before 01 Dec 1900 becomes < 01 Dec 1900
so, after 01 Dec 1900 becomes > 01 Dec 1900
so, about 01 Dec 1900 becomes ~ 01 Dec 1900
so, between 01 Dec 1900 and 01 Dec 1901 becomes < 01 Dec 1900 <> 01 Dec
1901.
To me much more presentable there are bugs which I live with and when
frustrated enough fix but hey ho that’s the beauty of GRAMPS
phil

1 Like