fix: stale data on wifi widget

[danielepintore]

Pull Request

If this PR is not ready for review yet, please mark it as Draft until it's good to be reviewed.

Motivation

closes #2184
I have noticed that when I am connected to a network and suspend my laptop, the Wi-Fi widget displays stale SSID data from the previous connection upon resuming in a new location. A similar issue occurs during automatic failover: if the primary connection drops and the system automatically connects to a saved hotspot, the SSID name in the status bar remains unchanged despite the successful reconnection.

This pull requests forces a scan to update the network list and reflect the latest changes when those events occur. I've also implemented a mechanism to start again nmcli -t monitor if the process for some reason hangs or exits

Type of Change

Mark the relevant option with an "x".

• Bug fix
• New feature
• Breaking change
• Refactoring

Related Issue

• Closes #(issue number) (if any)

Testing

Describe how you tested your changes and mark the relevant items.

• Tested on niri
• Tested on Hyprland
• Tested on sway
• Tested with different bar positions and density settings
• Tested at different interface scaling values
• Tested with multiple monitors (if applicable)

Screenshots / Videos

If applicable, include screenshots or videos to help illustrate your changes.

Checklist

• Code follows project style guidelines
• Self-reviewed my code
• No new warnings or errors
• Documentation or comments updated (if relevant)

[notiant]

The onResumed() function is unnecessary, the monitor process already triggers in this case. I think adding the scan there is enough to fix the problem with the stale SSID.

[turannul]

The scan is taking so much time due to --rescan yes - without that it doesn't work as expected.
UI has to get new scan results to refresh.
That is not the solution.

[danielepintore]

So if I've understood correctly I've to find a way to update the data without calling scan() or without the option --rescan yes right? I mean I've tested it and while the scan takes some time as you said I didn't see any problem on the bar

[turannul]

So if I've understood correctly I've to find a way to update the data without calling scan() or without the option --rescan yes right? I mean I've tested it and while the scan takes some time as you said I didn't see any problem on the bar

Correct.

In a perfect world, we shouldn't have store networks, instead read from dbus/iwd/wpa_supplicant/nm directly, (which one is most convenient) but that's wasn't possible at the time due to lack of API or dbus interface (within shell) didn't existed.

I wasn't allowed to write a noctalia-networkd and offload all the work and still not allowed to.

3-4 seconds actually acceptable tbh, i've saw worse (20 seconds sometimes or more)

edit: whenever you run scan in terminal, it has no effect to shell.

[turannul]

So if I've understood correctly I've to find a way to update the data without calling scan() or without the option --rescan yes right? I mean I've tested it and while the scan takes some time as you said I didn't see any problem on the bar

Correct.

In a perfect world, we shouldn't have store networks, instead read from dbus/iwd/wpa_supplicant/nm directly, (which one is most convenient) but that's wasn't possible at the time due to lack of API or dbus interface (within shell) didn't existed.

I wasn't allowed to write a noctalia-networkd and offload all the work and still not allowed to.

3-4 seconds actually good tbh, i saw 20s +

From what i remember without --rescan yes it only returned the network i've already connected to

adding secondary scan_fast() is not worth (to me) worth the complexity it brings.

I've tried making the interface in python it didn't bring 'expected' improvement either.

What you're seen it was best effort, without changing how things work.

[notiant]

I think to address the problem with stale data the current PR is fine given that this will be reworked anyway in v5? I would only drop the onResumed() function.

[turannul]

I think to address the problem with stale data the current PR is fine given that this will be reworked anyway in v5? I would only drop the onResumed() function.

data is stale because fetching new one taking (I already mentioned... There is no good way to fix it, at this point not worth bothering) long, and yes within v5 this should not be an issue.