@adriandavey
You can verify the version of the Addon in the Help → Plugin Manager.
If using the original Plugin Manager, scroll to the addon, select and use the Info button to see the currently running version.
If using the Plugin Manager enhanced, search for the addon name, select it and the currently running version will be displayed at the far right of the 1st line in the bottom panel.
if using an experimental version of the Plugin Manager:
That was yesterday and it looks like I had not closed gramps. It works now, I am on 1.2.8.
One thing that I think would help is for FilterParams to display the words “Name” and “Comment” left of the contents of those fields in the “Header block”.
The window containing the results of a test of a PERSON filter [where the person view displays NAME, ID, Gender, Birth Date, Birth Place, Death Date, Death Place, Spouse, Tags, Last Changed—in that order—contains just ID, NAME, Birth [Date], in that order, and then whitespace. Is there any means of configuring the columns displayed? When the same filter is run from the sidebar, the result contains the same columns in the same order as the current category view.
Yes, at present FilterParams displays the Name & Comment field contents tightly compressed immediately below the Category and Filter selectors, but if they happen to be of very uneven string length it is hard to distinguish between them. I use the comment field extensively to document whether the filter has been confirmed to work, and to list the other filters it calls. The need for the latter may diminish with the view FilterParams now provides of the nesting of filters, but I haven’t yet had enough time to evaluate that.
Personally, I’d rather see emojis used to distinguish between 2 fields. They only take the space of a couple glyphs and don’t require translation.
Yes, anything compact, but useful to distinguish the two.
How about just displaying the name in bold and the comment in normal (or dim) font or italics.
The columns are hardcoded in FilterParams. I don’t know if it would be worthwhile to make them configurable. Do you have a use case where running the filter from the sidebar would not be sufficient?
That would be a good solution
At this stage I am just trying to understand the behaviour of the FilterParams UI and the windows it opens. I am puzzled that sometimes the results of a test run are a window of ~1/3 screen width, sometimes ~50%, sometimes 100% [but offset about 20px to the right and thus partly offscreen]..
But it is hardly a “test run” if the results do not permit inspection of how it has handled at least one of the parameters determining the outcome. For example, when I test an Event filter that is intended to identify events with invalid dates, the result window for it does not include any date column, all I get is ID, type & description. If it is not practical to include at least one of the field(s) which is/are the focus of a query, it would be better to replace the Run test window with just a simple count of the objects it would return, or omit the Run test button altogether.
There has been a Gramps (not limited to FilterParams) bug affecting how repeatedly opened dialogs “walk” across the screen.
Would it make sense to inherit the shown columns, column order, column width and row sorting of the Flat List in that view category for the contents of the Results list?
That is what I was expecting, and it is what happens when you run the filter from the sidebar.
Reading through this, several of the pain points here — seeing filter dependencies, testing without reopening the editor, and sharing a complex filter — are exactly what pushed me to build a gramplet of my own, FilterWorkbench.
It takes a different angle from FilterParams: it’s built around the building flow, with helper filters as explicit named stages and a live match count that updates as you add rules. The Test button runs the filter in the person view without closing the builder, which is the “test without the useless wide window” itch from the first post.
I’ve written it up in its own thread if anyone wants a look: Here
Not trying to duplicate FilterParams — more a complementary take on the same problem.
Of course the difference there is … the gramplet isn’t spawning lots of new windows and doesn’t have to worrying about budgeting resources for each. It is just winnowing down what has already been spent. (The view was built. A filter just reduces the data in the view.)
I expect Kari was being judicious by limiting the resouce usage when there is an unknown number of rows coming. Which is particularly important since Filter Params can spawn a multitude of Test Result windows.
I have now made the following changes in FilterParams:
I don’t think it would be worth the effort to duplicate the functionality of the views (column configuration) in FilterParams.
You can run the filter in the sidebar while FilterParams remains open. Any changes done in FilterParams will be available in the sidebar after saving the filter.
I find the FilterParam Test Results to be an effective and navigable Worklist. When using a worklist, the more narrow, the better. (Unless you have excess screen space to space. But I’ve never seen screen space to spare.)
It frees the Category view to use other filters… or better yet, not be slowed by filters at all.
Kari, thank you for these changes. I would be even happier if there was also just a simple mechanism to LIST the dependent filters in some indented tabular form. I attach an example [anonymised] of the overview I have constructed in a word processor by laborious verification of downward successive filter syntax, using the sidebar filter editor UI.
I have belatedly come to realise that the “invert” box can get toggled extremely easily without intention by the user. Clicking anywhere on the FilterParams interface across the full-width row containing the word “invert”—even a very long way across the screen from the box—toggles its behaviour. This is NOT helpful. I can understand a buffer of a few px around the tickbox to allow for imprecision of mouseover, but the current behaviour is in my opinion extremely dangerous.
The Export does something akin to that. I copied an “export” and prompted Google Gemini AI:
<filters>
<object type="Person">
<filter name="EventFilter" function="and">
<rule class="MatchesEventFilter" use_regex="False" use_case="False">
<arg value="Cluttered Filter"/>
</rule>
</filter>
</object>
<object type="Event">
<filter name="Cluttered Filter" function="and" comment="Created by Filter+ gramplet on 2025-02-12">
<rule class="RegExpIdOf" use_regex="False" use_case="False">
<arg value="I"/>
</rule>
<rule class="HasEventBasePlus" use_regex="False" use_case="False">
<arg value="Birth"/>
<arg value="from 2 to 2182"/>
<arg value="e"/>
<arg value="a"/>
<arg value="some"/>
</rule>
<rule class="HasTag" use_regex="False" use_case="False">
<arg value="Complete"/>
</rule>
</filter>
</object>
</filters>
It responded:
This XML snippet defines two connected filters (likely from the genealogy software Gramps, given the reference to “Filter+ gramplet”): a primary Person Filter and a secondary Event Filter that it relies on.
Here is what the XML translates to in plain English:
Overview
Find all People who match a specific Event Filter named “Cluttered Filter”.
Breakdown of the Rules
1. Person Filter (
EventFilter)
- Target: Person objects
- Logic: Finds people associated with events that meet the criteria defined in the “Cluttered Filter” below.
2. Event Filter (
Cluttered Filter)
- Target: Event objects
- Logic: An event must satisfy ALL three of the following conditions (
function="and"):
- ID Matching:
- The Event ID contains the letter “I” (case-insensitive, non-regex).
- Event Type & Time/Role Criteria:
- It is a Birth event (or a event derived from a Birth base type).
- It occurred within the date range from year 2 to year 2182.
- Additional specific internal parameters (
e,a,some) set by the Filter+ plugin.
- Tag Criteria:
- The event is tagged as “Complete” (case-insensitive).
In Plain Summary
“Find any Person who is linked to a ‘Birth’ event (dated between years 2 and 2182) that has an ID containing ‘I’ and is tagged as ‘Complete’.”
At least while I have to remain on gramps 5.1.4 [AIO64-5.1.4-1 under Win10pro], FilterParams [1.2.9] appears to be unstable.
I am wondering if various GTK issues are getting in the way here? The problem of toggling the invert boxes might also be in play, because the row in which the inadvertent toggling can happen extends all the way to the right to the scrollbar, which is fairly narrow.
Quite often FilterParams scrolls through the constituent filters with considerable difficulty, as if the scrollbar was extremely sticky. And THREE times now in less than 48 hours, running a freshly-opened instance of gramps, I have had FilterParams crash, taking gramps with it, AND requiring me to break the lock to open the tree again, even though no “edit” or “ok” had been touched in the session before the crash. My normal frequency of this kind of gramps crash is only 1 or 2 in quite a few months, and then usually as the termination of a very long active session editing hundreds of objects [and most often when attaching and/or revising a place to an event].
Conditions to reproduce [tentative]—