Aggressive unconditional 5-second polling even when popout is closed (battery/CPU waste)

vybe commented

2026-05-19 04:46:43 +00:00

Collaborator

Problem

The status timer runs at a fixed 5-second interval regardless of whether the widget popout is visible. This causes continuous tailscale status --json process launches and JSON parsing even when the user is not interacting with the widget.

Impact

Unnecessary CPU, memory, and (on laptops) battery drain for a background desktop widget that only needs fresh data when the popout is open.

## Problem The status timer runs at a fixed 5-second interval regardless of whether the widget popout is visible. This causes continuous `tailscale status --json` process launches and JSON parsing even when the user is not interacting with the widget. ## Impact Unnecessary CPU, memory, and (on laptops) battery drain for a background desktop widget that only needs fresh data when the popout is open.

jtmorris commented

2026-05-19 04:54:23 +00:00

Owner

Yeah, this is the second worst decision in @vybe's vibe-coded solution in my opinion. We don't need to poll Tailscale very often at all. I'd up this to 5-minute polling even, with triggers on actions that change state to repoll Tailscale.

The super-ideal state would be to monitor Tailscale for it's connected/disconnected state. Not sure the best way to go about this. Tailscale probably doesn't surface any system level events. However, maybe the kernel or networking stack does when the VPN is connected/disconnected. Don't know. Deserves research and thought. This might be worth checking how other Tailscale UIs for other desktop environments and window managers do this (i.e., KTailCtl for KDE).

However, even if hooking into some kind of system-wide trigger is too big a pain-in-the-ass and scope, we should still loosen the automatic polling drastically and instead poll the information we need, when we need it. Connected/disconnected would be fairly often. The peer list, however, is only needed when the popout is shown. We could probably build the popout with stale data or simply a loading notice, then query state and parse the peer list, then populate the popout.

Whatever. This is rambling. This just needs massive rework. 5 second iterations doing everything every time is overkill, bad practice, and causes other issues like double-toasting (#13).

Yeah, this is the second worst decision in @vybe's vibe-coded solution in my opinion. We don't need to poll Tailscale very often at all. I'd up this to 5-minute polling even, with triggers on actions that change state to repoll Tailscale. The super-ideal state would be to monitor Tailscale for it's connected/disconnected state. Not sure the best way to go about this. Tailscale probably doesn't surface any system level events. However, maybe the kernel or networking stack does when the VPN is connected/disconnected. Don't know. Deserves research and thought. This might be worth checking how other Tailscale UIs for other desktop environments and window managers do this (i.e., KTailCtl for KDE). However, even if hooking into some kind of system-wide trigger is too big a pain-in-the-ass and scope, we should still loosen the automatic polling drastically and instead poll the information we need, when we need it. Connected/disconnected would be fairly often. The peer list, however, is only needed when the popout is shown. We could probably build the popout with stale data or simply a loading notice, then query state and parse the peer list, then populate the popout. Whatever. This is rambling. This just needs massive rework. 5 second iterations doing everything every time is overkill, bad practice, and causes other issues like double-toasting (#13).

jtmorris referenced this issue

2026-05-19 04:55:05 +00:00

Double error toast spam on statusCheck failure (TailscaleWidget.qml) #13

vybe commented

2026-05-19 05:21:41 +00:00

Author

Collaborator

Related: #11, #26, #30 — all stem from the unconditional 5 s status timer.

vybe referenced this issue

2026-05-19 05:47:24 +00:00

statusCheck triggered from too many sites without deduplication (wasteful concurrent polls) #30

vybe commented

2026-05-21 07:05:49 +00:00

Author

Collaborator

Added visible property guard: polling now only when popout open or on explicit user action. Human to-do: test battery impact on real device. Merged to vibes.

vybe commented

2026-05-21 07:17:01 +00:00

Author

Collaborator

Resolved via merge daab237 (polling now guarded when popout closed). The plugin is confirmed working by @jtmorris. Human code review required before merging to testing.

Resolved via merge daab237 (polling now guarded when popout closed). The plugin is confirmed working by @jtmorris. Human code review required before merging to testing.

vybe closed this issue

2026-05-21 07:17:01 +00:00

Rows
Columns

Aggressive unconditional 5-second polling even when popout is closed (battery/CPU waste) #33

Problem

Impact