[Feature Request] Reporter filtering improvements for now and the future

[barjac]

Contact Details

G4MKT G6WPJ GW4GTE GW8LJJ GW3OAJ

Feature for this project

Over the last few months FreeDV usage has increased considerably and this is causing problems for users of the FreeDV Reporter.

In our opinion the only way to keep the number of stations shown in the reporter at any one time relevant to the user, will be to allow 'user configurable filters'.

As things stand now I will try to summarize the comments I am hearing and the problems being encountered:
Station cannot keep track of the stations in the group as the list is dropping off the page.
Most stations on the frequency are only listening but taking up screen space.
Stations on the same frequency showing on the list are out of radio range (daytime NVIS) e.g. USA or Japan showing in the UK.
Stations on the list are camping there 24/7 and causing over long lists that no longer even fit a full screen.
The list goes on...

All these issues could be solved with lots of dedicated filters, however that would cause endless feature requests for different use cases.

A structured, user configurable filtering scheme is needed.
The user would be able to create named filters for selection in different use cases in an easy to use GUI.
Each filter could use any or many reporter column values to narrow down the displayed stations.

Two possible examples:
UK_NVIS_net:- Exclude distance greater than 1000 miles, exclude mode RX Only, exclude Last TX greater than 30mins ago, exclude where Msg does not start with a numeric character (in UK nets we use this to indicate that a station wishes to TX and the order of net).

DX_20m:- Exclude distance less than 2000 miles, exclude mode RX Only, exclude Last TX greater than 1 hour ago.

Obviously we can't expect users to insert regex, but the following could be used in setting up filter conditions in a small table with one condition per row:

 < less than
 > greater than
 = equal to 
 ! not
 ^ starts with
 N numeric character
 ~= contains

Filter Name: | UK NET
___________________________________
1 | Dist      | <  | 1000          |   ( Dist in current reporter units)
2 | Status    | != | "RX Only"     |   
3 | Last TX   | <  | 60            |   (mins) (or blank)
3 | Msg       | ^  | N             |

EDIT: If the filter was set to 'exclude' the filtered items then maybe:
 ___________________________________
1 | Dist      | >  | 1000          |   ( Dist in current reporter units)
2 | Status    | =  | "RX Only"     |   
3 | Last TX   | >  | 60            |   (mins) (or blank)
3 | Msg       | !^ | N             |

I appreciate that this would involve a fair amount of work, however in the long run it would 'future-proof' the reporter against more and more filtering requests as user numbers increase.

VHF/UHF

None

Deprecated features

None

Non-standard compiler

None

Legal worldwide

None

Implementation assistance

Help with structure ideas

Support assistance

Testing as always.

[barjac]

Thinking practically, if the filter definitions were stored in files named as the filter name, then passing filters among users would be simple.

[tmiw]

Interesting idea. Since we're already integrating Python into FreeDV, what are your thoughts about having the filters be definable by some sort of Python/other language function you can include? i.e. create uk_nvis_net.py with something like this:

from FreeDVReporter import User, Mode

def is_filtered(row: User) -> bool:
    return row.distance > 1000 or row.mode == Mode.RX_ONLY or ...

def filter_name() -> str:
    return "UK_NVIS_net"

Note: this definitely wouldn't be trivial due to security, etc. concerns, so not necessarily recommending this approach.

Also, would there be some set of filters that come with FreeDV by default? And if so, what would those be?

[barjac]

Initially I think we need to consider the user input method first. Only after that has been decided, start to consider the best approach to achieve it programatically.

User input needs to be really, really, simple and GUI, certainly no reference to programming languages.

A single drop down list like the Msg entry box in the reporter footer to select existing filters would be the only user visible change, with minimal space required.
Left click the box to enable the current filter - background turns amber.
Spin the wheel to select a different filter.
A context menu accessed while hovering the box could offer to:

• Create a new filter
• Edit a filter
• Delete a filter

To create a new filter I envisage a GUI with an entry box for the new filter name and a table of 3 columns, the field in column 1 would hold a nested pick list of all the reporter column names, the field in column 2 would hold a pick list of all the conditional operators available e.g. greater than, less than, not etc. in plain text. The field in col 3 would hold value which may be from a pick list and/or 'user typed'.
Any number of rows may be added with one condition per row to further constrain the filter.

To edit a filter the same logic as the 'create' could be used but with the current filter values pre-loaded and the option to save under a new name for the case where a minor variation on an existing filter was also required.

Regarding filters pre-installed in the program, then yes, I see that as useful, if only to use as examples. Basic 'idle', 'RX only' and 'max distance' filters are fairly generic ones that immediately spring to mind.
Filter name lengths need to be limited to save real estate unless an elipsis approach as in the Msg entry box would not be overkill. I prefer short names.

[barjac]

Out of curiosity I asked AI (Claude) about whether the table based approach with pick lists would be feasable using wxGTK, I also pointed it here to give it more context whilst also pointing out that I am not a developer. ;)

Here is it's output:

Your Design is Sound
Your table-based approach with "Parameter | Condition | Value" is exactly right for non-technical users. This is a proven pattern used in database tools, email filters, and spreadsheet applications.
Refinements to Consider

1. Simplify the operators for users:
   Instead of showing <, >, !=, ^, ~= which might intimidate non-programmers, use plain English in the pick lists:

For Distance/Last TX: "less than", "greater than", "equal to"
For Status/Mode: "is", "is not"
For Msg/Callsign: "contains", "does not contain", "starts with", "does not start with"

The code would translate these friendly terms to the actual operators behind the scenes.
2. Include/Exclude toggle:
Your EDIT about "exclude" vs "include" logic is important. I'd suggest adding a simple radio button or checkbox at the top of the filter:

○ Show only stations matching these conditions (AND logic)
○ Hide stations matching these conditions (exclude/NOT logic)

This avoids confusing users with "not equal" vs "equal" mental gymnastics.
3. Smart value fields based on parameter:
When the user selects a parameter in column 1, column 3 should adapt:

Distance: Numeric entry field (with unit label showing current units)
Status: Pick list only ("TX/RX", "RX Only", "TX Only")
Mode: Pick list only (700D, 700E, 800XA, etc.)
Last TX: Numeric entry with unit (minutes/hours pick list?)
Msg: Text entry field
Callsign: Text entry field (maybe with autocomplete from known stations)

4. Condition operators based on parameter:
   Similarly, column 2 (condition) should show only relevant operators:

Numeric fields (Distance, Last TX): "less than", "greater than", "equal to", "between"
Text fields (Msg, Callsign): "contains", "does not contain", "starts with", "ends with", "is exactly"
Status/Mode (pick lists): "is", "is not"

This prevents users from trying to do "Distance contains text" which makes no sense.

Implementation Suggestion for Developers
For the FreeDV developers, here's a structure that would make this maintainable:

// Define filter parameters with metadata
struct FilterParameter {
    wxString name;              // "Distance"
    wxString columnName;        // "dist" (reporter column)
    enum Type { NUMERIC, TEXT, ENUM } type;
    wxArrayString enumValues;   // For Status, Mode, etc.
    wxString unit;             // "miles", "mins", etc.
};

// Each row in the filter table
struct FilterCondition {
    FilterParameter* param;
    wxString operation;        // "less_than", "contains", etc.
    wxString value;
};

This lets you add new filterable columns easily in the future without rewriting the filter UI.

Save/Load Filter Presets

Your named filters idea is crucial. Users should be able to:

1. Create a filter (e.g., "UK_NVIS_net")
2. Save it
3. Select it from a dropdown later
4. Share filter definitions with other users (export/import)

Store these as simple JSON or INI files in the user's config directory.

Visual Mockup Concept

Filter: [UK NVIS Net ▼] [New] [Save] [Delete]

☑ Show only stations matching ALL of these conditions:

┌─────────────────────────────────────────────────────────┐
│ Parameter      │ Condition       │ Value               │
├─────────────────────────────────────────────────────────┤
│ Distance ▼     │ less than ▼     │ [1000] miles       │
│ Status ▼       │ is not ▼        │ RX Only ▼          │
│ Last TX ▼      │ less than ▼     │ [60] minutes ▼     │
│ Message ▼      │ starts with ▼   │ [0-9]             │
└─────────────────────────────────────────────────────────┘
[+ Add Condition] [- Remove Selected]

[Test Filter] Shows: 12 stations     [Apply] [Cancel]

Bottom Line
Your idea is excellent and very implementable with wxGrid. The key to success will be making the UI intuitive enough that non-technical hams can create filters without consulting documentation. The suggestions above aim to hide the technical operators behind user-friendly language while still giving power users the flexibility they need.
You've identified a real problem and proposed a scalable solution. Well done!

[tmiw]

I think we'll need to discuss this more as a project team and get back to you. I'll update here if I have anything new to share.

[Tyrbiter]

Something to consider is will other stations be frustrated when a filter is removing them from the view of a local net? Maybe it's a case of choose your poison but the Reporter is very useful and we must be careful not to ruin its utility.

[barjac]

Something to consider is will other stations be frustrated when a filter is removing them from the view of a local net?

Its unlikely that all net members would be filtering the same way or even at all, someone would be seeing them. I certainly would not try to filter out anyone obviously listening to a net that I was involved in.

Maybe it's a case of choose your poison but the Reporter is very useful and we must be careful not to ruin its utility.

I can't think how something that enhances its usability is likely to ruin it.

The reporter's success could be its downfall if the rapid increase in FreeDV usage continues at the current rate. A flexible filter system could help to keep its displayed content manageable.

Bear in mind that the ability to enable/disable filters with a single click is a crucial part of this proposal.

[Tyrbiter]

I understand your comments @barjac I made mine purely to ensure that we don't accidentally throw the baby out with the bathwater.

I am noticing some problems with the larger number of stations too, some can be mitigated now, some can't. I'm generally in favour of this proposal for that reason.