Feature request from Discussions #860 (VeeN13): let a saved Filter Profile optionally carry a highlight color (text/background/map pin), so highlighting stays in sync with filter criteria instead of being recreated separately (as in GSAK's Mfilter → Waypoint→Highlight split workflow).
Proposed v1 scope:
Add optional highlight_enabled, text_color, bg_color, pin_color fields to FilterProfile's JSON schema
Reuse FilterSet.matches(cache) for per-row evaluation, decoupled from the active list-narrowing filter
Note: profiles containing a WhereClauseFilter need one SQL pre-run per profile to populate _matching_ids before matches() works correctly
Priority-ordered list of highlight-enabled profiles in the Filter Profile Manager; first match wins (no color blending)
Re-evaluate on the same triggers as other derived per-row visuals (db load, cache edit, profile edit)
Related but separate from the filter-criteria parity work tracked in #821.
Feature request from Discussions #860 (VeeN13): let a saved Filter Profile optionally carry a highlight color (text/background/map pin), so highlighting stays in sync with filter criteria instead of being recreated separately (as in GSAK's Mfilter → Waypoint→Highlight split workflow).
Proposed v1 scope:
Add optional highlight_enabled, text_color, bg_color, pin_color fields to FilterProfile's JSON schema
Reuse FilterSet.matches(cache) for per-row evaluation, decoupled from the active list-narrowing filter
Note: profiles containing a WhereClauseFilter need one SQL pre-run per profile to populate _matching_ids before matches() works correctly
Priority-ordered list of highlight-enabled profiles in the Filter Profile Manager; first match wins (no color blending)
Re-evaluate on the same triggers as other derived per-row visuals (db load, cache edit, profile edit)
Related but separate from the filter-criteria parity work tracked in #821.