[Feature Request]: Node list filtering by number of hops

[wjg57]

Checklist

• [x] I have used the search function for OPEN ISSUES to see if someone else has already submitted the same feature request.

• [x] I have also used the search function for CLOSED ISSUES to see if the feature was already implemented and is just waiting to be released, or if the feature was rejected.

• [x] I will describe the request with as much detail as possible.

• [x] This request contains only one single feature, not a list of multiple (related) features.

• [x] I have read and understood the Contribution Guidelines.

• [x] I agree to follow this project's Code of Conduct

Contact Details

[email protected]

Feature or improvement you want

Within the node list: allow filtering by number of hops, i.e. only display nodes that are "closer" than a given number of hops, with the default value set to the number of hops defined in the LoRa configuration.

This could replace the "Only show direct nodes" filter entry - direct nodes are nodes that are just one hop away - with a pull-down (?) to define the number of hops to show, potentially highlighting the limit set in the LoRa configuration.

An alternative (simpler but more restrictive) implementation could be an additional filter setting ("Only show reachable nodes"?) that limits the list to the number of nodes actually reachable with the current limit set in the LoRa configuration.

Why should this be added?

Currently the node list in areas with many nodes contains a lot of "uninteresting" nodes, i.e. nodes that cannot be reached because they are farther away than the number of hops configured in the LoRa configuration section.

Although it is already possible to sort the node list by number of hops, the sheer number of unreachable nodes currently displayed clutters the list.

Screenshots / Drawings / Technical details

I'm not a UI specialist, so I have no idea whether the implementation of a pull-down for the number of hops with in the filter list pull-down is feasible or desirable. I also have no clue whether better alternative solutions are possible.

The second suggested implementation should definitely be possible, albeit less functional.

[DaneEvans]

sort by : hops away - why does it need to be a filter rather than just the sorted list?

[prokrypt]

sort by : hops away - why does it need to be a filter rather than just the sorted list?

So that we can sort by last heard (or distance, etc) without seeing nodes we might not be able to reach.

[pedjas]

+1

[DaneEvans]

on hold til #3716 goes through - it refactors this code and should be used as a base

[github-actions[bot]]

This issue hasn not had any comment or update in the last 30 days. If it is still relevant, please post update comments. If no comments are made, this issue will be closed in 7 days.

[pedjas]

bump