Refreshing the data and especially sending a HTTP request to healthchecks every 15 seconds seems to be a bit often for background operation. This could be adapted depending on the following conditions:
- borgmatic status (running, error, inactive)
- menu (and log output submenu) open or not
- interesting events (systemctl state/condition event, healthchecks ping/deadline)
- started via button
Still, the durations displayed in the menu could be refreshed every second if the menu is open without requiring polling of the data sources. Healthchecks probably only needs updates around the "interesting events" (or between different borgmatic app backup steps), while we need to poll systemd regularly to find out when these happen. This could boil down to the following 4 config variables: {ACTIVE,INACTIVE}_{SYSTEM,BORGMATIC}_POLL
Further ideas:
Refreshing the data and especially sending a HTTP request to healthchecks every 15 seconds seems to be a bit often for background operation. This could be adapted depending on the following conditions:
Still, the durations displayed in the menu could be refreshed every second if the menu is open without requiring polling of the data sources. Healthchecks probably only needs updates around the "interesting events" (or between different borgmatic app backup steps), while we need to poll systemd regularly to find out when these happen. This could boil down to the following 4 config variables:
{ACTIVE,INACTIVE}_{SYSTEM,BORGMATIC}_POLLFurther ideas: