#941·xbar

document how to deal with plugin state

Author: selloutCreated Oct 29, 2025Updated Oct 29, 2025

Given some comments like https://github.com/matryer/xbar/issues/133#issuecomment-169642832 and https://github.com/matryer/xbar/issues/609#issuecomment-784281354, it seems like xbar doesn’t manage state at all, but lets the script just do file IO.

This is fine, but

  1. it took a while to discover,
  2. I’m still not sure if that’s all there is to it, and
  3. there are probably some useful suggestions you could make.

Some of the suggestions I can think of are like

  • “put files in ~/Application Support/xbar/plugin-state/<plugin-name>/” (or maybe …/xbar/cache/<plugin-name>/)
  • or maybe it’s the opposite – “don’t dump stuff into xbar’s directory”
  • locations that are likely to be more or less successful given macOS’ capabilities & restrictions (e.g., I don’t want some notification like “my-script.py is asking for full filesystem access” to come up)

my actual problem

(In case there’s an existing approach that solves my use case in some way.)

In my particular case, I have a plugin that fetches data from the Internet every minute. When it fails (like the many times my laptop is offline when traveling), I just get an error in my menubar. But, it doesn’t need to fetch data constantly – only when the IP address has changed since the last run. So, I plan to store the IP address I had when I last fetched, as well as the fetched data (which is a single number). If we’re offline, we just use the most recent number, and if we’re online we fetch if the IP address doesn’t match.

variants

  1. I don’t have to store the IP – I can just fetch regardless if online, and use the file otherwise.
  2. I could store each IP address as a separate filename, with the only content being the number – then I only have to fetch the first time I have a new IP (maybe I update the modification time when I read the file, and then can use that to clear out old IPs and that lets me know which one I should use when offline, too).
  3. Could use the modification time to check if the last IP information is particularly stale, and indicate staleness in the menubar.