I’ve been building a gramplet I call FilterWorkbench (Danish: Filterværksted), and after reading the recent thread on the custom filter editors I thought it was worth sharing here for feedback.
It grew out of my own frustration with building multi-stage person filters — the kind where one filter references another, which references another. Keeping track of what matched what, and testing without constantly reopening editors, got painful fast.
What it does
Live match count — the number of matches updates as you build, so you see the effect of each rule immediately instead of running the filter afterwards.
Test without closing — a Test button applies the filter to the person view while the builder stays open, so you can keep iterating.
Helper filters — reusable, named sub-filters that the main filter can reference. This makes multi-stage cascades explicit and readable: each stage is a numbered, named row with its own match count.
Import / Export — filters can be shared as text, so a complex filter can be handed to someone else without describing every rule by hand.
Per-tree storage — filters are kept per database, separate from Gramps’ own custom_filters.xml.
How it relates to FilterParams
FilterWorkbench takes a different angle — it focuses on the building flow: composing a filter out of helper filters, watching the match count change live, and testing in place. I see it as complementary rather than a replacement to Gramps Filter editor.
Status
Tested on Windows (Gramps 5.2 and 6.0) and Linux (6.0.8).
Ships with a Danish translation and a README + GUIDE.
Not in the Addon Manager catalog yet — for now it’s a manual install from GitHub.
On the “open with default viewer” idea: the report already opens in the system default browser as soon as it’s saved, on both Windows and Linux, so that outcome is covered out of the box (it uses the system default, so no browser is hard-coded).
One caveat I ran into: on my own Linux box it pops up a “which browser?” dialog — but that’s because I haven’t set a default browser on that machine, not the report itself. On a system with a default set, it just opens silently.
If what you’re after is control over that behaviour, I’m happy to add a Document Option to suppress the automatic open, for anyone who’d rather just have the file written without a browser tab spawning. Let me know if that’s what you had in mind.
So everyone understands, the FilterWorkbench is an alternate to the creating, and running of custom filters.
The create and edit filter window, because of the size font I use in themes, overflows the viewable monitor space top to bottom. The window’s top is at the top of the monitor while the bottom of the window extends below the lower edge of the monitor. It needs scrolling capabilities.
It seems to be a library / curator for Custom Filter too.
It does not directly share the custom_filters.xml resource user by the Filters Gramplet, export filters, or for filtering options in many Reports and Tools.
I think that it is supposed to help with GUI overload when the list of bespoke filters grows too long. It should let infrequently-used Custom Filters be moved in-and-out of the active workspace without being lost.
Then it needs an ability to convert and add a filter, or set of filters, used by Gramps so that it can be used in reports and other tools. If not, a user would need to recreate their efforts.
I’m not sure this answers your question, but FilterWorkbench’s filter can already be used in reports and other tools that require a filter. It just requires that the desired filter is used in the person overview. This will make it visible in all Gramps filter lists as wb…
FilterWorkbench works with exactly the same filters as Gramps Filter Editor. I don’t have the V5.1 version on my PCs myself. It would be interesting to know if it works in V5.1. I think it will work, but I can’t promise anything.
I am not convinced that the separate “helper” category is an enhancement, and it is meaningless to say that helper filters can be re-used when any gramps filter can be reused by another [if it makes sense to do so!]. You could say that every filter that is not a “Main filter” [in FilterWorkBench parlance] is a “helper filter”. But why can’t both be both? One of many frustrations with the gramps builtin filter options is that the classification into different categories is not particularly intuitive and you sometimes waste considerable time working out where in the arcane structure the filter you need has been hidden, then iteratively navigating down a quite long and complicated path to get to it for as many instances of it as you need.
The separation in FilterWorkBench seems to limit me, in that—
(a) on the main UI, I can only directly edit a “main filter”, and can only edit a helper after first opening a main
(b) on the edit UI, it seems I cannot export a help filter?
(c) it seems I cannot transfer filters between main & helper?
I am in the dark as to what is meant to happen when I click on the “Test filter” button in the upper pane of of the FilterWorkBench edit UI. It goes through a minute or so with a dialog telling me that various filters are being applied, but does not open any additional window or view. Is the the fact that it did not display an error or crash meant to tell me it worked? Its tally of the matches does appear to be correct for what I was attempting.
Likewise “Reset view” does not appear to do anything but tie up system resources for about 40s [for a filter with 14K matches], and no change in the stats or display?
In either case, at no point did the people view behind the FilterWorkBench UI change.
I now have to conclude that the limitation of FilterWorkBench to the the person view only makes it less suitable for my needs than the gramps filter editor [limiitations of the latter notwithstanding].
Both Gramps AND FilterWorkBench give access in the Person view filter editor [in the Event filters category] to the filter “People with events matching the EVENT FILTER …”
But the filter “Events of places matching the PLACE FILTER …” is only available from the Event view in Gramps. This means that creating or editing any event or place filter can only be done in the Gramps editor.
That is a deal breaker for me. If I can’t access place filters from FilterWorkBench then it becomes a fairly pointless exercise for me.I have a substantial number of records from Denmark, Sweden, Channel Islands, England, Ireland, Australia, New Zealand, Canada & US, so filtering on jurisdiction at countyprovince/state/territory/national levels is often a starting point for many of my working filters.
Life for all of us would be a lot easier if the sidebar field for “Place” had a radio button to toggle it between a string search on the name, to an “Enclosed by” search. That will definitely be one of the enhancement requests I put into the bugtracker in the next week or two.
It might seem that there could be a workaround in FilterWorkBench by using the Place field in the Event category options for the two filters People with the BIRTH DATA or … DEATH DATA, but these have the same limitation as the sidebar, in that they provide a string search, not an “enclosed by” one. There might be a few circumstances where this is workabe, but usually you want all events within the jurisdiction you are currently working on.
Thanks for spelling this out so clearly — you’ve put your finger on exactly the boundary. FilterWorkbench lives entirely in the person namespace, so it can reference an existing event filter (via “People with events matching the …”) but it can’t build or edit the event and place filters themselves — those only exist in the Event and Place view editors. For a jurisdiction workflow that means the place → event → person chain can’t be assembled in one place, which I can see makes it a non-starter for you.
Rather than bolt other namespaces onto FilterWorkbench, I think there’s a cleaner fix: a custom person rule that does the enclosure test internally. Something like “People with an event in a given place (and everything enclosed by it)”, with an option for the event type (birth / death / any) and an “inclusive” toggle to count the place itself.
Because it’s a single person-namespace rule, it collapses the whole place → event → person chain into one step: you pick the rule, give it a place ID, and that’s it — no separate place or event filter to build, and it works directly in FilterWorkbench and in Gramps’ own Custom Filter Editor. It reuses Gramps’ own located_in() logic, so “enclosed by” means exactly what it does everywhere else in Gramps — transitively, all the way down the hierarchy.
One question before I build it, so I make something you’ll actually use: does jurisdiction filtering as a single person rule cover your starting point, or do you routinely chain it into larger event/place filters that would still need real cross-namespace editing? If it’s the former, this drops straight into your workflow; if it’s the latter, the rule helps but won’t replace place/event filter editing on its own.
Either way it would be a standalone rule add-on (like my other filter-rule add-ons), so nothing in FilterWorkbench itself changes — the rule just appears in the rule list once it’s installed.
