The hardest part of this for the indicator is knowing exactly when to start doing extra scans.
The indicator-network service has no idea when the indicator menu itself is actually opened. For this to work both unity8 and qmenumodel would need to be modified to support the "submenu-action" convention. (https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1398888)
Adding a filtered model between the raw APs and the current APs based on the last-seen property would be reasonably straight-forward.
My main objection would really be that there should really be a consistent strategy for AP aging across all clients. So, e.g. unity7 and unity8 will have the same behaviour.
The hardest part of this for the indicator is knowing exactly when to start doing extra scans.
The indicator-network service has no idea when the indicator menu itself is actually opened. For this to work both unity8 and qmenumodel would need to be modified to support the "submenu-action" convention. (https:/ /bugs.launchpad .net/ubuntu/ +source/ unity8/ +bug/1398888)
Adding a filtered model between the raw APs and the current APs based on the last-seen property would be reasonably straight-forward.
My main objection would really be that there should really be a consistent strategy for AP aging across all clients. So, e.g. unity7 and unity8 will have the same behaviour.