Eww style Basic Var

[JustSimplyKyle]

Is your feature request related to a problem? Please describe. Not exactly a problem, but just an annoyance

Describe the solution you'd like Add support for variables, like eww's defvar this would reduce the required scripting to make it work. Without this, I would have to use external scripts to save the state into a lock, which works, but get tedious real quickly. Although this feature is probably out of scope to this issue anyway

Describe alternatives you've considered using script and lock.

Additional context https://github.com/JakeStanger/ironbar/issues/70 originates in this issue

[JakeStanger]

So my understanding of how it works in Eww:

1. You declare variables in your config (optionally with a default) and reference those.
2. The variables can be updated externally, via a CLI or some other mechanism to talk to Eww.
3. Any elements using the variable automatically update when the variable changes to show the new value.

I think in principal basic support would be simple, but there's a lot to consider to get it right:

• How does Ironbar listen to the changes? Presumably a Unix socket would be the best call?
• Should the client for communicating with Ironbar be part of the same binary, or shipped independently? My concern is adding too much weight into the project when it already takes a good while to compile.
• Where would the variables be supported? Supporting them inside every option would create a huge amount of work, but implementing them in only a few places might be confusing.
• Is there an easier way to achieve what you want? Perhaps just a few helper scripts that can do common tasks like creating lock files would solve the problem.
• Anything else?

[JustSimplyKyle]

How does Ironbar listen to the changes? Presumably a Unix socket would be the best call?

A simple unix socket should be fine.

Should the client for communicating with Ironbar be part of the same binary, or shipped independently? My concern is adding too much weight into the project when it already takes a good while to compile.

I think the same binary should be fine. Compiling time could be a concern, in that case you could just make this an optional feature.

Where would the variables be supported? Supporting them inside every option would create a huge amount of work, but implementing them in only a few places might be confusing. In the ideal world, supporting it in every option would be the best. But I understand that that might be too big an amount of work. So I think supporting it in just script(and maybe custom?) would be fine.

Is there an easier way to achieve what you want? Perhaps just a few helper scripts that can do common tasks like creating lock files would solve the problem.

Helper scripts work just fine. The most common use case is just for boolean values so the show-if trick I showed in discussion should work. But I just think it's an hassle to set up in general, and the best one can minilize is just merging it into one binary and give it a flag.

Anything else?

Thanks for you work! Ricing ironbar has been a much nicer experience then what eww and waybar gave me. (Side note: is there a time where there is a lowest limit on interval, it seems like since then, it has been removed)

[JakeStanger]

I think the same binary should be fine. Compiling time could be a concern, in that case you could just make this an optional feature.

Yep, if it does go in the main binary I definitely will have it under a (enabled by default) feature flag.

The most common use case is just for boolean values so the show-if trick I showed in discussion should work.

This is why I'm a little reluctant to jump straight into implementing this. There may be an easier/cheaper win for this specific scenario. I'll have a think about it!

---

I meant anything else worth considering for this issue btw, but thanks for the kind words :P Trying to make it as easy to configure is possible is one of my main goals, so I'm glad that's holding up so far.

is there a time where there is a lowest limit on interval Nope, never has been other than "what your PC can handle".

[JakeStanger]

Another thought - another possible use-case for the socket/CLI would be keybindings to open popups.

[JakeStanger]

Tracking this in #199 along with the related CLI/IPC (#91).

The current implementation works as follows:

• The IPC (and CLI by extension) offers a set <key> <value> command and a get <key> command.
  • Any valid UTF-8 value is accepted for keys and values. All values are strings.
• You can bind to a variable by sticking ${variable}} in dynamic strings (ie anywhere that a script could go to result in text).
  • This syntax is not final and I'm very open to ideas about it.
  • The scope where they can be used will also be expanded over time, but I want to get some feedback now before it goes any further.

Example:

$custom = { type = "custom" bar = [ { type = "label" label = "Hello, ${greeting}}" }  ] }

ironbar set greeting world

would display "hello, world" on the bar. Running set again will live update the greeting.

There is no need to declare variables anywhere, simply referencing one is enough to create it. It will render as blank until set.

Variables are set globally for the running instance of Ironbar, so will apply to all bars. They persist for the application lifetime.

[JustSimplyKyle]

How about @variable? or #variable? Cause iI think it's easy to miss the last bracket in ${var}}

[JakeStanger]

#variable might be a good shout. It needs to be something that doesn't conflict with bash syntax ideally, and I think that should do the job nicely

[JakeStanger]

Although thinking about it...staight up #variable could cause problems because people will almost certainly want to include a # in their labels at some point, and then you gotta worry about escaping it, whereas I'd rather minimise the need for that.

The current implementation also allows for spaces in variable names, although that might have to change.

I'd also like the script and variable syntax to be similar enough to be vaguely intuitive and keep parsing simple.

I can see the following possible routes forward:

• ((varaible)) or [[variable]] or some other "double wrapping" of the variable name to show clearly where it starts/ends.
• Use single-wrapping, but pick a symbol that won't cause an issue with this. For example {variable} might work here (bash experts please correct me!), or #variable#.
• Use a prefix only (like #variable), remove support for spaces in variable names, and add some kind of escape character.
• Use {{double_braces}} for both scripts and variables, but add a prefix to the front of each. For example, you might have a ${{script}} and a #{{variable}}.

I think the 2nd option is my favourite personally. Interested to know what you think, or if there's a preference on characters to use?

[JustSimplyKyle]

I'm fine with either the 2nd or the 3rd 3rd is imho more nice to my eyes, but it also do that at the cost of spaces We could follow Hyprland's way, by doing "##it_twice" to escape it Anyway, I would love to see other people's opinion on this Since it's not easily possible to change syntax after the release

[JustSimplyKyle]

Another possible route(admittedly horrible) is... Completely omitting the syntax of variable syntax! Since we already have the command ironbar get <stuff>, there is no need for the extra syntax

[yavko]

That would require polling tho, and would have a delay, I think the benefit of this feature would be the ability to get rid of polling. Making a separate command that instead watched is also possible, but that wouldn't be as performant or reactive would it?

[JustSimplyKyle]

Yeah, I personally would go against that either Just listing possible ideas Maybe a do poll(vote) somewhere?

[yavko]

I have another idea, we could take a page out of windows' CMD %variable_name%, since afaik % isn't used anywhere in bash.

[JustSimplyKyle]

https://stackoverflow.com/questions/125281/how-do-i-remove-the-file-suffix-and-path-portion-from-a-path-string-in-bash It's also used in bash!

[JustSimplyKyle]

https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Brace-Expansion https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Shell-Parameter-Expansion hmm, might be a problem since the shell parameter expansion used up every single symbol easily accessiblee

[JakeStanger]

We could follow Hyprland's way, by doing "##it_twice" to escape it

I think this might be okay, since I'd imagine variable usage is gonna outweigh the usage of a literal hash.

Since we already have the command ironbar get , there is no need for the extra syntax

As yavko says, this effectively nullifies the whole feature. With this, Ironbar would just be providing a key/value store to absolutely no benefit.

I have another idea, we could take a page out of windows' CMD %variable_name%, since afaik % isn't used anywhere in bash.

This would also work. % is used but I don't think there's a case where you'd have something %wrapped%. Personally though I'm not a fan. I've always hated that Windows uses percent signs for vars.

Since it's not easily possible to change syntax after the release

Obviously I'd rather not if I don't have to, but if we do find it's problematic I am willing to make the change. Ironbar is alpha still, and a large part of the reasoning behind that is to give room to make big breaking changes where required.

---

Taking in all of the above, here's what I'm thinking:

• Let's go with #variable, since that's simple.
• I'll remove support for spaces in variable names, bc their use is limited anyway and it just complicates things.
• ## can be used as an escape for a single literal hash.
• If we end up with some edge case where a hash is used in expansion or some other wacky mechanic, I'm almost certain that ## will cover it or it will be possible to implement a fix for.

Thoughts?

Are we also happy with the current {{script syntax}}?

[yavko]

I agree #variable is the simplest, and doesn't have any conflicts