476 negative searches for location

[gracemyz]

@kchall , this branch also contains the movement negative search update, so you'll be able to test both movement and location here

[kchall]

@gracemyz Woops, I can't actually run this branch:

Traceback (most recent call last):
File "/Users/KCH/Desktop/SLPAA/src/main/python/main.py", line 3, in
from gui.app import AppContext
File "/Users/KCH/Desktop/SLPAA/src/main/python/gui/app.py", line 7, in
from .main_window import MainWindow
File "/Users/KCH/Desktop/SLPAA/src/main/python/gui/main_window.py", line 54, in
from search.search_builder import SearchWindow
File "/Users/KCH/Desktop/SLPAA/src/main/python/search/search_builder.py", line 45, in
from search.search_models import SearchModel, TargetHeaders, SearchValuesItem
File "/Users/KCH/Desktop/SLPAA/src/main/python/search/search_models.py", line 27, in
from search.helper_functions import *
File "/Users/KCH/Desktop/SLPAA/src/main/python/search/helper_functions.py", line 422, in
def filter_modules_by_locn_paths(modules: list[LocationModule] | list[RelationModule], target_paths, nodes_are_terminal, matchtype='minimal', terminate_early=False, is_relation=False, articulator=None):
TypeError: 'type' object is not subscriptable

[gracemyz]

@kchall sorry about that -- i had used type checking syntax that's only available for more recent versions of Python. I've removed it.

P.S. since I'm not done updating Relation yet, I haven't tested search targets with mov+rel or loc+rel target types. Pure movement or pure location targets should work fine.

And a quick question: I also updated the branch to handle some edge cases with the "nodes are terminal" checkbox. Here I made an assumption that if the match type is exact then we treat "nodes are terminal" as being true, even if the checkbox is unchecked. Is this reasonable?

[kchall]

@gracemyz Thanks, this is working now! So far, it mostly seems good in terms of the actual targets and results I have tried.

1. Is it known / intentional that the 'this location is neutral' box is not functional yet?

E.g. if I select that on its own as a location target, the search returns all signs, regardless of whether they have that box checked or not, and when I re-open the search target, the box is no longer checked.

If I check the box and select 'purely spatial,' signs are returned, but again only ones that are purely spatial, regardless of having the 'neutral' box checked. And, when I go back to try to edit the search target, I get an error message:

2. Actually -- while when I started testing things, I could edit any of my search targets, I now no longer can edit any of them; I get a similar error message trying to edit any of them, but different key errors:
   KeyError: 1755103419.59989
   KeyError: 1755104595.088644
   ...etc.

Re: terminal nodes and exact matches -- this is probably okay, but I was trying to test out a couple of cases to make sure I got the expected results, and ran into a different error. I set up a location target as H1, Body, Cheek-ipsi, and set the search type to be positive but exact, and got the following error:

[gracemyz]

Just a quick response about the key errors and not being able to edit search targets: I know this happens when you double-click on one of the signs returned in the search results to view the sign details. Unfortunately that functionality is buggy. It should be possible to avoid the key errors by viewing the signs in the main corpus window instead. Sorry about all the errors -- I'll take a look over the next few days!