I’m trying to tweak the libwebconnect module to work with places, but cannot figure out what’s going wrong. Most probably something trivial as I’m new to the gramps development, and hope someone can provide a hint how to proceed.
def make_place_dict(dbstate, handle):
"""
Create a dictionary to hold values for replacing in URLs.
"""
results = {
"parish": "",
}
place = dbstate.db.get_place_from_handle(handle)
if place:
results["parish"] = place.get_name().value
return results
Trying this results in that in the Places interface right-clicking will not result in any menu item with the place internet link above, but in the People it looks like expected (but trying to follow a link will naturally throw an error as I deleted the make_person_dict call above).
Hence, it feels like the error cannot be in the make_place_dict, as it still pops up for People. So what have I been missing that disqualifies links for places?
I am not a coder so cannot answer your direct questions, but as an active user of the functionality I am very much interested in this topic.
The code indicates that it should work for all parts of the database. The FRWebPack.py has search entries for both Place and Source (admittedly commented out '#'). But even making them active, the Web Connections on right-click does not present itself.
IF the existing code could be made to function on places, the Title field is now hidden so most users do not have information entered in it. What you are attempting to do, the Name field, or the automated place name, should be returned for the search.
Continued attempts to find out the origin of the problem, it looks like it boils down to how Gramps finds out which Add-ons that are applicable for certain data types. For instance, in the case of the SVWebPack.py (and most probably for the other languages too) the make_search_functions in libwebconnect is never called from the load_on_reg in the py with all link patterns.
Hence, how does Gramps figure out this? There is an attribute navtypes which can be used as part of the registration, but that one is by default set [] assuming it means that in this case the applicability is decided by some other means.
Reaching out to you creating add-ons, as it feels the problem is not really with the libwebconnect and patterns files, but when they will be used.
While you are looking at the WebConnect pack, you might want to consider whether the interface approach could be improved.
The separation into different download for different languages doesn’t make a lot of sense. These only difference between packs are the search string patterns being used with the variable substitutions.
It seems like that could be done like Gramps handles translations everywhere else.
And it would make a lot more sense as a Gramplet instead.
So if there was a simple list (similar to the current pop-up menu) but with checkboxes, you could select several sources and execute simultaneous queries, one browser window for each query.
e.g., you select “Ancestry”, “WikiTree”, and “FamilySearch”, then click the Search button… 3 windows pop. You change Active Person & click Search again. Another 3 windows pop.
Down the line, an interface could be layered on that would simplify adding/changing search strings without hacking the code.
I did not see in the code how libwebconnect.py created “Web Connection” on right-click. That is being done in the main code at gramps\gui\plug\quick\_quickreports.py. Not sure if this bit of information is relevant but maybe…
Yes, feature request systems are sometimes a place where good ideas go to die. The Gramps-Project is no better (or worse) than other development projects in this aspect.
But, in combination with a discussion forum, sometimes such ideas can be jump-started.
Sometimes because the discussion piques the interest of an experienced developer. But it can also introduce a group of like-minded users to one another. And the mutual support begins crowd powered experiments which nudge the code forward.
There are other MantisBT issues gathered with the “Web Connect Pack” tag. And there are good leads & information to be found through exploring them. For instance, looking through Resolved items that have Pull Requests associated with them can help guide people to chunks of code that affect specific things.
Time spent connecting MantisBT issues with “Tags” & “Relationships” can help gather like-minded users & developers too.
I had a go with trying to add a copy of the code (1) for Place instead of Person in listview and add Place item to connection file and building a dict for Place in libwebconnect, but that resulted in some weird xml being generated and throwing an error (2). Looking at the xml it seems like the submenu with the place connections ends up outside of the meny part at the end (3).
Hence, I’m stuck… This must be a trivial error, but setting up a development environment to trace all actions feels overwhelming right now. Any ideas on what’s going wrong, or at least where it happens?
(1)
# Web Connects
if self.QR_CATEGORY == CATEGORY_QR_PERSON:
(web_ui, web_actions) = create_web_connect_menu(
self.dbstate, self.uistate, self.navigation_type(),
self.first_selected(), prefix)
if self.get_active() and web_actions:
actions.extend(web_actions)
self.at_popup_menu.append(web_ui)
(2)
9004: ERROR: grampsapp.py: line 174: Unhandled exception
Traceback (most recent call last):
File "C:\Program Files\GrampsAIO64-5.1.4\gramps\gui\views\listview.py", line 936, in _button_press
self.uimanager.update_menu()
File "C:\Program Files\GrampsAIO64-5.1.4\gramps\gui\uimanager.py", line 230, in update_menu
self.builder.add_from_string(xml_str)
File "AIO/gi/overrides/Gtk.py", line 464, in add_from_string
GLib.GError: gtk-builder-error-quark: <input>:1367:1 Unhandled tag: <submenu> (1)
(3)
</menu><submenu>
<attribute name="label" translatable="yes">Web Connection</attribute>
<item>
<attribute name="action">win.web-con-0</attribute>
<attribute name="label">(32) Begravda i Sverige 2</attribute>
</item>
</submenu></interface>