Track VPN activation and deactivation locally while nmrs operations are
running. This lets the applet show a spinner immediately, refresh state
while NetworkManager settles, and clear pending state on completion or
error.
Also use VPN-specific icons for VPN rows and prefer active or pending VPN
state for the panel icon.
Only mark an nmrs Wi-Fi group as activated when the group itself is
active. Access points inherit device state, so inactive known networks on
a connected Wi-Fi device can otherwise appear activated and get skipped
from the known networks section while also being filtered out of visible
networks.
- Strip the CIDR suffix (/24) from the shown IPv4 address
- Sort visible wireless networks by signal strength again
- Filter out empty-SSID "hidden network" entries from the list
Fixes a bug where we showed `Activated` networks after the current active
one.
Also ipv4/6 addresses were merged so this seperates them and only shows ipv4
for now until we decide the best way to show both, UI/UX wise.
`cosmic-applet-network` listed every connection from `nm.list_saved_connections()` in the VPN dropdown, including the in-memory-only profiles NetworkManager auto-generates for externally-managed interfaces (e.g. a `wg-quick@wg0.service` tunnel). Toggling such an "assumed" connection off deletes it from NM — it was never persisted — leaving a dead toggle with no way back through the applet or `nmcli con up`.
Skip connections flagged `unsaved` (in-memory only) at the `load_vpns()` site so they no longer get a togglable entry. The active-connections section still shows the interface as connected (read-only). One-line change in `cosmic-applet-network/src/app.rs`.
## Test plan
- Built on Pop!_OS and ran the patched `cosmic-applet-network`: with `wg-quick@wg0` up and NM tracking `wg0` as connected-externally, the VPN dropdown no longer shows the destructive `wg0` toggle; the active-connections section still shows `wg0`; Wi-Fi toggling is unaffected.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Unstable sorting should be slightly faster than stable sorting, and if
the vector was built asynchronously then preserving the initial order
doesn't matter too much.
Continue to use stable sorting where the vector is not built
asynchronously, or if the vector is partially sorted (e.g. when new
elements are pushed to a sorted vector).
