I am running Gramps 5v1v5 on Mint Linux.
When a filter is created or modified it does not get included in the list of Custom Filters which is generated on Gramps start-up.
Would it be possible for the Custom Filters list to be recreated whenever a filter is modified or created?
Could you test that with a step-by-step workflow and share the workflow?
I created/modified custom filters on 5.1.5, 5.1.6, 5.2.0 and 5.2.1 on Windows and Fedora. All those custom filter changes survived restarting Gramps. (The fields in the Filter gramplet were flushed for each session though. I had to use Filter+ to scrape those parameters to create reloadable custom filters.)
I wonder what youâre doing differently?
Run Gramps
create new filter
run report which can use the newly created filter
The report will see the new filter only because it has the following code in the Options
# Reload filters to pick any new ones created since Gramps was loaded
from gramps.gen.filters import CustomFilters, GenericFilter
self.__filter = FilterOption(_("Select using filter"), 0)
self.__filter.set_help(_("Select Notes using a Note filter"))
filter_list = []
filter_list.append(GenericFilter())
filter_list.extend(CustomFilters.get_filters('Note'))
self.__filter.set_filters(filter_list)
menu.add_option(category_name, "filter", self.__filter)
Pylint complains that using
from gramps.gen.filters import CustomFilters, GenericFilter
outside of init is not liked.
But regardless of what pylint thinks, the code will run within Gramps.
II just think there should be a more pretty way of updating the Custom Filters.
Are you asking if the Signals and Callbacks system has a signal for the Custom Filter list? And, if so, how to leverage it?
I would not know if that is what I meant. Can you translate?
Gramps has Signals that are emitted when things change. For instance, some feature are keyed off the Active Person. So if those features can be set to passively âlistenâ (or âconnectâ) for the specific Signal emitted when the Active Person is changed and trigger an update. (This is also the way the GUI can âlistenâ for each type of button to be clicked and act on that.)
The FilterParams addon by @kku connects to the signal that a custom filter has been change so that it can update its display and filter list. Maybe looking at that code will be more clear.
So, Gramps has a signal, âNew Filterâ, which alerts those parts of the program that a new filter has been added.
The question is, why doesnât it prompt a re-read of the Custom Filters.
Lovely translation, thanks.
It just signals. The developer has to decide what is an appropriate reaction.
Iâd expect that you will want to reâread on 4 filter signals shown in that code:
- add_new_filter
- delete_filter
- on_filter_changed (think this is a change of which is selected)
- edit_filter
My point is if these signals exist in Gramps, why doesnât Gramps update the Custom Filters.
In a large program like Gramps, using signals like these is tantamount to passing the buck. âIâve done my bit, it is someone elseâs job to action it.â
If there is no one looking for the signal, then it is a waste of time setting it.
I think that is is exactly the opposite of that. It means that it allows growth without adding redundant monitoring to bog down the core.
Also, remember that the core Gramps engine is only loosely tied to the interface. This allows Gramps to run as a headless system, a CLI driven, a GTK based GUI, potentially another GUI toolkit in the future that not supports our current OSes but mobile platforms too⌠like Flutter.
Also, some of the recent performance boosts for mass changes take advantage of deliberately not acting on each signal. So doing mass deletes in a view doesnât re-run the filter and refresh the display after each record. It does that after all the deletes are done. So a 20,000 person deletion can be completed in seconds instead of HOURS.
But if there is no one acting on the signal at all, as seems to be the case with the Filter changes, there is no point in having the signal in the first place.
The signal is being used in quite a few areas. However, typically the modal dialogs (like when running Reports or Exports) can safely ignored.
Iâm not sure whatâs happening in your case. Running a report would normally poll the current list of Filters. Which are updated regularly as they are committed in one of the filter editing features.
Are you doing something to add/change a filter AFTER initializing the report?
(There are a couple Tools that Iâve discovered that store a filter as part of their .ini
and donât bother to re-poll the list if the tool is called within the same session. I recall filing an issue report for one tool.)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.