Clarification on implementation of `xbar.var` metadata

[Cueball]

[Didn't want to be necromancing #160 a year later, so opening a new issue for clarification on this feature.]

I'd very recently switched over to SwiftBar, on the basis of it (seeming) to be more actively maintained. Additionally, SwiftBar states:

"Plugin API is adopted from the BitBar\xbar, which means that SwiftBar can run any existing BitBar\xbar plugin."

IMHO that means SwiftBar is claiming to be a drop-in replacement with the same features. But SwiftBar doesn't/won't support xbar.var metadata:

• That's regularly going to break scripts written for xbar when they're updated (whether manually or automatically).
• The point of xbar.var settings is that custom user-prefs for each plugin gets stored in a JSON store outside the script itself (the "sidecar" JSON file)
• Having xbar.vars provides:
  • The user var values are pulled directly from the JSON file.
  • The user doesn't have to set any environment vars for a plugin.
  • The user doesn't have to manually edit a bunch of prefs into the script.
  • The user pref data doesn't get erased when a plugin is updated/replaced.
• From comments in #160:

  "each time I come across a plugin that relies on parameterization, I just modify it for my needs. ChatGPT is surprisingly good at doing this, so it’s basically free."

• Modifying a script each time a plugin is updated is specifically what xbar.var is intended to eliminate.
• FTR swiftbar.environment - doesn't meet the same use-case.

Unclear to me whether #160 is still applicable now, particularly with the major version bump in early 2025.

Questions:

1. Trying to understand what the objection to xbar.var is/was?
2. Is xbar.var objectionable in principle, or is it simply a not-yet-implemented feature?
3. Would a PR addressing the missing functionality be accepted? [^1]
4. If xbar.var is definitively off the table, could that be clearly documented as an incompatibility?

[^1]: I'm not quite in a position to submit a PR on this rn; if/when I am, happy to put in some yards towards a PR, but not if it's likely to be rejected on principle.

[melonamin]

Very well articulated issue, thank you for taking the time.

I don't have strong objections against this feature, this is just something I never felt the need for personally and didn't see the demand(in form of issues).

On the high-level it shouldn't be hard to add support for this, let me give it a shot.

[Cueball]

Got a bit sidetracked and just seen this. Happy to assist in testing (limited capacity for anything else until we're well into 2026…)