A new WebSearch gramplet is ready

Development
203

I know… :shushing_face:

+++ /usr/lib/python3/dist-packages/gramps/grampsapp.py	
@@ -29,8 +29,8 @@
 # -------------------------------------------------------------------------
 import logging
 
 LOG = logging.getLogger(".")
@@ -202,7 +202,7 @@
 #
 # -------------------------------------------------------------------------
 
-MIN_PYTHON_VERSION = (3, 8, 0, "", 0)
+MIN_PYTHON_VERSION = (3, 6, 0, "", 0)
 if not sys.version_info >= MIN_PYTHON_VERSION:
     logging.warning(
         _(

+++ /usr/lib/python3/dist-packages/gramps/gui/grampsgui.py	
@@ -53,7 +53,7 @@

 MIN_PYGOBJECT_VERSION = (3, 12, 0)
 PYGOBJ_ERR = False
-MIN_GTK_VERSION = (3, 24)
+MIN_GTK_VERSION = (3, 22)
 UIDEFAULT = (
     """<?xml version="1.0" encoding="UTF-8"?>
 <interface>

https://gitlab.gnome.org/GNOME/gtk/-/raw/ef1a1b5cb1010977d631dc1131b0db45a1e1e15f/NEWS

204

There is an other variable, as the json list will return some strange domain names. I can understand that the small (maybe pre-trained) model could provide “broken” urls (linter). The prompt is maybe a source of “orientation/direction”, which will “format” the answer. There is still a lot of differences between an “API session” like with the WebSearch gramplet and a “Web access” like with Mistral Web interfaces (ie. my comments on your PR on github) . Maybe model versions are not the same? Anyway, with or without an update, I just see minor differences (eg., around FamilySearch and Ancestry sub-domains in UK or Europe). So, it seems that the cooking recipe is still hidden by Mistral AI, at least on free API key (token status?).

The strange feeling might be related to the “temperature” set for the model. Current return is giving the impression that the proposal has been generated by OpenAI! So, for me, it seems a little bit too strict.

I know that “Experimental Plan” is for experimentations, but I used agents for setting one tested model. So, like into WebSearch gramplet.
The query via the API knows that my preferred language is french (according to csv order into the list), but maybe it supposes that I am in Canada or that I am a Franco-Belgo-Canadian!!!

205

A new WebSearch version is available on Github: v0.57.38

The updates list:

  • Updated fr-links.csv
  • Changed sorting rules in the column with icons
  • WebSearch links are reloaded immediately after Settings saving
  • Set default note type to “Person Note” when saving a link as a new note
  • Refreshed links list when switching between Gramps categories (pages)
  • Showed success/failure notifications when creating a new note
  • Grouped all checkbox settings under unified “Show” sections, similar to other sections

Updated settings fragment:

image
image1398×504 61.5 KB

206

The UID links are misbehaving. The URLs are not substituting in the actual IDs, instead they are appending %(FamilySearch.personID)s (and I’m not sure why the version number are SO much different between the 5.2 branch at 0.58.41 and the 6.0 branch at 0.43.28 )

image
image1282×550 78.9 KB

image
image1279×762 91.8 KB

207

I’ve requested two PRs several days ago. One of them is already approved and another one isn’t yet.

One question before I will try to repro the issue: do you use json-file in your custom directory? I made renaming of variables to keys. Maybe your file still has “variables”?

208

You asked make this replacing in the column. I did it in the new release. But it also means I need sync naming in README and in all other files to avoid confusing users

A valid fragment:

[
  {
    "nav_type": "Person",
    "attribute_name": "_FSFTID",
    "url_regex": ".*familysearch\\.org/.*/tree/person/details/.*",
    "key_name": "FamilySearch.personID"
  },
  {
    "nav_type": "Person",
    "attribute_name": "_FSFTID",
    "url_regex": ".*familysearch\\.org/.*/tree/pedigree/landscape/.*",
    "key_name": "FamilySearch.personID"
  },
  {
    "nav_type": "Person",
    "attribute_name": "WikiTreeID",
    "url_regex": ".*wikitree\\.com/wiki/.*",
    "key_name": "WikiTree.ID"
  },
  {
    "nav_type": "Person",
    "attribute_name": "GeniID",
    "url_regex": ".*geni\\.com/people/.*",
    "key_name": "Geni.ID"
  },
  {
    "nav_type": "Person",
    "attribute_name": "WeRelateID",
    "url_regex": ".*werelate\\.org/wiki/Person:.*",
    "key_name": "WeRelate.ID"
  },

Here variable_name is renamed to key_name

209

@emyoulation give me know pls if you still have the troubles

210

I wiped out the WebSearch folder in the gramps52/plugins and re-extracted from a fresh ZIP.

I have not tried to make any custom .csv or .json files since you implemented the separate folder option.

211

Got it. I will test json keys and fix it today. Thank you!

1 Like
212

@emyoulation could you check the fix pls: Release v0.58.41 · jurchello/WebSearch · GitHub *(for Gramps 6.0 in .gpr.py)

Or simply make this replacement on your side in model_row_generator.py:

Does it work now?

213

Some additional information.
I changed the way I replace keys in url-templates. Now the replacement in the code works through regular expressions. For users, everything remains the same. But using regular expressions allows us to simplify templates. We all can move to templates like {birth_year} instead of %(birth_year)s. If you are interested, let me know and I will make the changes and we will simplify it in the templates.

2 Likes
214

Websearch 0.58.41 from Addon Manager fails on MacOS due to missing package ‘requests’. Mac users cannot use pip (unless they are very advanced)

Bug filed

215

There was not a 5.2 branch update in your repository (and the 0.58.41 version available from the Addon Manager still has the problem.) So I downloaded 0.58.40 from the 6.0 branch and tweaked the target version from 6.0 to 5.2

And yes, that allowed WebSearch to work again. (Despite the version being indicating it being one revision earlier.)

By the way, for the FindAGrave in the us-links.csv, can there be a gender addition? The Surname for women is typically a maiden name. But the “Last name(s)” entered on FindAGrave is typically their final spouse’s surname. The maiden name is infrequently entered in their system. But the following will increase the matches. (But it would decrease accuracy to apply this option to searches for male names.) :
&includeMaidenName=true

from us-links.csv

People,Find A Grave,1,https://www.findagrave.com/cgi-bin/fg.cgi?page=gsr&GSfn=%(given)s&GSmn=%(middle)s&GSln=%(surname)s&GSby=%(birth_year)s&GSbyrel=in&GSdy=%(death_year)s&GSdyrel=in&GScntry=0&GSst=0&GSgrid=&df=all&GSob=b,
216

Is this package is required? If so, that requirement ought to be specified in the .gpr.py file… regardless of the OS

I already had requests installed because it is one of the requires_mod requirements for the FamilySearch addons by @jmichault

217

No, it should not be required. I will fix this issue.

218

Got it, thank you for the check. I will add it to the new PR for gramps-addons. At the same time the gramplet versions will be synced.

219

Could you check pls the final url, is it what you are expecting?

People,Find A Grave,1,https://www.findagrave.com/cgi-bin/fg.cgi?page=gsr&GSfn=%(given)s&GSmn=%(middle)s&GSln=%(surname)s&GSby=%(birth_year)s&GSbyrel=in&GSdy=%(death_year)s&GSdyrel=in&GScntry=0&GSst=0&GSgrid=&df=all&GSob=b&includeMaidenName=true
1 Like
220

Are the extra parameters necessary? I usually try trimming them out. (On the assumption that each extra parameter increases the linkrot risk.)

221

Im not sure. If you have ability, you can test it more deeply with and without parameters. Then I can remove all the extra params which you will list.

1 Like
222

Test version privately provided fixes the ‘request’ issue.

1 Like