@Brinycoolie
Thanks for your suggestion! I’ve also thought of this before, but it seems I haven’t put this on my list yet.
Currently there is a “Filter result” badge to highlight the results of the sidebar filter (see here). Unfortunately, this can be extremely slow for complex filters, since the filter is applied to each person individually, not once to all people in the database. This can slow down the building of the tree considerably.
To solve this, I plan to change/enhance the badge interface so that a callback can be run once for each tree rebuild to do general operations like filtering (i.e. applying the filter only once for each tree), and the callbacks for each person are much faster.
As a side note, it would be nice to be able to hash the filter somehow to detect changes. I tried to do this for the sidebar filter, and it seems to work in my tests since the filter is completely recreated when the user changes something in the sidebar, but I wasn’t sure if this was always the case. For example, instead of recreating the whole filter, the filter rules could change without noticing this using a top-level hash. I don’t do this not-so-reliable hashing because it could cause the tree not to be updated even though the filter has been updated. If anyone knows of a reliable way to detect filter changes using a hash or something similar, I’m open to ideas.
I also plan to enhance the badge interface to allow the badge developer to provide settings to the user, e.g.
- Change the color of the badge
- Select a string/character/icon to display in the badge (e.g. if the main info is not the content of the badge, but that the badge appears for a person/family at all)
- Select an item from a drop-down menu
- etc.
The badge developer could use a drop-down menu to let the user choose from the list of custom filters. This way, the user could define a filter, select that custom filter from the badge’s drop-down and select a color as well as a character/icon for that badge. This would work once the interface enhancement is implemented.
However, relying on this interface would limit this to only one filter per registered badge. The best solution might be to just implement this directly in FTV, not in a separate registered badge. I’ll add this to my TODO list.