Thanks, that’s it. They were all role problems indeed.
Another one is, that for a gay couple, I get two warnings. One says, that it’s a gay couple, and the other says that the wife is a man. Would the latter go away when I change his role from Primary to Groom?
And a wish: When I download persons from FamilySearch, some persons have birth dates with a range with from and to, instead of between … and …, and in most cases the latter is what people meant, that they are not sure, not that the birth took more than a day, so I’d love to see a warning for this too, in case that I forgot to intercept it beforehand.
Before pushing the commit, please add a line 8… include yourself in the list of contributor dated copyrights.
Another future feature to manage your workflow would be a ‘distance’ sorting option.
Calculate the degree of distance from the Home Person and sort the closest Alerts to the top.
a “verify_tool_more_rules” with 17 commits (that include the 2 commits in PR#1550) but has not had a Pull Request submitted
I looks like you just need to make a 5.2 Pull Request for “Verify tool more rules” and GitHub will deal with the overlap.
@Nick-Hall - does Oliver’s PR need to be against the Gramps-Project/gramps Master or maintenance/Gramps52 ? Should he cancel PR1550 first? (1550 has lots of good commenting)
I have rebased PR #1150 onto the gramps52 branch and merged it.
Another pull request against the gramps52 branch can be created for the remaining changes. I suggest that we squash the commits down to just two: new rules and performance enhancements.
The first two are existing messages from old rules, so no idea what might be triggered when I change them (all existing translations for those two must be adjusted? No idea)
But yes - I can fix the phrasing later this day.
I noticed that after closing that verification tool quite some data remains referenced and can’t be garbage collected. I’m now adding those to utilize the given feature for explicitly destroying the objects on close.
I wonder if there isn’t a more general way to destroy the whole ManagedWindow instance after close because there are still leftovers on the heap which can’t be collected because they are still referenced.
We could add all those properties like i did with the 5 to get them deleted - but is that the way to do?
We had a problem in the past with garbage collection of Gtk objects. The track_ref_for_deletion method was created to overcome this and it is perfectly acceptable to use it.
The Uncollected Objects should always be empty after a reset. I have fixed a few such bugs recently.
@Nick-Hall ok, there are numerous self.something variables registerd in verify.py’s main window Class which are abviously not freed after the window is closed. Just that I understand you correctly - are you suggesting to hunt them down and call track_ref_for_deletion for each of them? It’s fine for me - I just want to do it “the right way”.
OK, I managed to find some troubling variables which I registered with track_ref_for_deletion. I’m now down to 8 uncollected objects - with not much further luck getting rid of them so far. I guess its already way better than it is in master right now (down from over 30 Objects to now 8)