JakeStanger/ironbar

Fork 0

mirror of https://github.com/JakeStanger/ironbar.git synced 2026-07-11 06:15:21 +01:00

[GH-ISSUE #419] Allow Dynamic String parsing for "ironvar_defaults" #8571

New issue

Open

opened 2026-05-23 03:52:51 +01:00 by JakeStanger · 7 comments

JakeStanger commented

2026-05-23 03:52:51 +01:00

Owner

Originally created by @izelnakri on GitHub (Jan 25, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/419

While building my own very advanced & custom ironbar, I noticed currently ironvar_defaults doesnt accept Dynamic String parsing. This is a big missing feature I think because:

1- Although I can accomplish the retrieval of pretty much any value in my operation system with Dynamic Strings, scripts or bash one-liners, having all the important metadata in ironvar_defaults seems like a good/best practice. That way I can get basic information of my operating system outside my configuration file as well, by running $ ironbar get disk-usage-percentage etc.
2- Having them as a variable that can be watched/polled routinely would DRY up a lot of repetitive bash one liners or hand rolling custom scripts. Example:

{
  "ironvar_defaults": {
    "disk-usage-in-percentage": "{{30000:df -h / | awk 'NR==2 {print $5}'}}",
    "disk-usage-in-gb": "{{30000:df -h --output=used / | awk 'NR==2 {print $1}'}}"
  },
  "start":  [
        {
          "type": "label",
          "label": "🗄️ #disk-usage-in-percentage [#disk-usage-in-gb]"
    }
  ]
}

This way I can also access these variables from outside the configuration via:

$ ironbar get disk-usage-in-percentage, without having to repeat the expressions inside and outside of the ironbar configuration file.

Originally created by @izelnakri on GitHub (Jan 25, 2024). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/419 While building my own very advanced & custom ironbar, I noticed currently `ironvar_defaults` doesnt accept Dynamic String parsing. This is a big missing feature I think because: 1- Although I can accomplish the retrieval of pretty much any value in my operation system with Dynamic Strings, scripts or bash one-liners, having all the important metadata in `ironvar_defaults` seems like a good/best practice. That way I can get basic information of my operating system outside my configuration file as well, by running `$ ironbar get disk-usage-percentage` etc. 2- Having them as a variable that can be watched/polled routinely would DRY up a lot of repetitive bash one liners or hand rolling custom scripts. Example: ``` { "ironvar_defaults": { "disk-usage-in-percentage": "{{30000:df -h / | awk 'NR==2 {print $5}'}}", "disk-usage-in-gb": "{{30000:df -h --output=used / | awk 'NR==2 {print $1}'}}" }, "start": [ { "type": "label", "label": "🗄️ #disk-usage-in-percentage [#disk-usage-in-gb]" } ] } ``` This way I can also access these variables from outside the configuration via: `$ ironbar get disk-usage-in-percentage`, without having to repeat the expressions inside and outside of the ironbar configuration file.

JakeStanger added the

T:Core Enhancement

A:Config

labels

2026-05-23 03:52:51 +01:00

JakeStanger commented

2026-05-23 03:52:51 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jan 25, 2024):

This is an interesting one. I do have concerns around implementing this exactly as you have above because it's cyclical - this would result in Ironvars which accept dynamic strings which accept ironvars which accept...

Technically that may be possible (I'd have to look to find out how much work) but I worry that it'd introduce a lot of edge cases, risk the feature becoming more computationally expensive, and add a steeper learning curve. Preventing recursion might be easier said than done.

What might be a better approach is a new config option for defining top-level scripts that can be used across the bar. New syntax could be added into dynamic strings for 'script references' to use these. This wouldn't be as powerful as the full dynamic string, but would allow you to define once and re-use, and could also provide the same optimisation of requiring a single process per script.

For example (bikeshedding the syntax here):

{
  "scripts": {
    "disk-usage-in-percentage": "30000:df -h --output=used / | awk 'NR==2 {print $1}'"
  },
  "start": [
    {
      "type": "label",
      "label": "$disk-usage-in-percentage"
    }
  ]
}

I do also have plans in the future to expose some internal values as read-only ironvars, which may negate the need for this completely. For example, you might be able to reference #upower.battery_percent. That needs a lot of planning and is probably a long way off currently though.

@JakeStanger commented on GitHub (Jan 25, 2024): This is an interesting one. I do have concerns around implementing this exactly as you have above because it's cyclical - this would result in Ironvars which accept dynamic strings which accept ironvars which accept... Technically that may be possible (I'd have to look to find out how much work) but I worry that it'd introduce a lot of edge cases, risk the feature becoming more computationally expensive, and add a steeper learning curve. Preventing recursion might be easier said than done. What might be a better approach is a new config option for defining top-level scripts that can be used across the bar. New syntax could be added into dynamic strings for 'script references' to use these. This wouldn't be as powerful as the full dynamic string, but would allow you to define once and re-use, and could also provide the same optimisation of requiring a single process per script. For example (bikeshedding the syntax here): ```json { "scripts": { "disk-usage-in-percentage": "30000:df -h --output=used / | awk 'NR==2 {print $1}'" }, "start": [ { "type": "label", "label": "$disk-usage-in-percentage" } ] } ```` I do also have plans in the future to expose some internal values as read-only ironvars, which may negate the need for this completely. For example, you might be able to reference `#upower.battery_percent`. That needs a lot of planning and is probably a long way off currently though.

JakeStanger commented

2026-05-23 03:52:51 +01:00

Author

Owner

@izelnakri commented on GitHub (Jan 25, 2024):

I like the approach of making computed properties getter-only, as long as we have plan to make them accesible from outside with something like ironbar get #upower.battery_percent. I really appreciate how you think through these advanced features, it's still rare in the open-source, so thank you! :)

This idea of internal module development in rust/or smt, and then making them exposed via $ ironbar get and available as references in configs(like how nix language does it) is very powerful idea I think, I like it!

@izelnakri commented on GitHub (Jan 25, 2024): I like the approach of making computed properties getter-only, as long as we have plan to make them accesible from outside with something like `ironbar get #upower.battery_percent`. I really appreciate how you think through these advanced features, it's still rare in the open-source, so thank you! :) This idea of internal module development in rust/or smt, and then making them exposed via `$ ironbar get` and available as references in configs(like how nix language does it) is very powerful idea I think, I like it!

JakeStanger commented

2026-05-23 03:52:51 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jan 25, 2024):

I like the approach of making computed properties getter-only, as long as we have plan to make them accesible from outside with something like ironbar get #upower.battery_percent

Yeah that's the vague plan. They'd be ironvars, so they'd be registered through the same internal service and usable through all the current systems you can currently. Just using ironbar set would error.

I don't like rushing into these things because it always becomes a pain later down the line. I also want the discussion to be open as possible, as people often have better ideas than me :) Very glad to see that does come across

@JakeStanger commented on GitHub (Jan 25, 2024): > I like the approach of making computed properties getter-only, as long as we have plan to make them accesible from outside with something like ironbar get #upower.battery_percent Yeah that's the vague plan. They'd be ironvars, so they'd be registered through the same internal service and usable through all the current systems you can currently. Just using `ironbar set` would error. I don't like rushing into these things because it always becomes a pain later down the line. I also want the discussion to be open as possible, as people often have better ideas than me :) Very glad to see that does come across

JakeStanger commented

2026-05-23 03:52:51 +01:00

Author

Owner

@izelnakri commented on GitHub (Jan 25, 2024):

What do you think of making configurations accept config.nix in addition of config.json, then maybe it could also have recursive set references: https://nixos.org/manual/nix/stable/language/constructs#recursive-sets

I think benefits might outweight the costs.

@izelnakri commented on GitHub (Jan 25, 2024): What do you think of making configurations accept `config.nix` in addition of `config.json`, then maybe it could also have recursive set references: https://nixos.org/manual/nix/stable/language/constructs#recursive-sets I think benefits might outweight the costs.

JakeStanger commented

2026-05-23 03:52:51 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jan 25, 2024):

I've looked in the past, and integrating Nix as a library into an existing program doesn't seem plausible (at least not without an enormous amount of work). The best case is probably evaluating it to JSON and loading that, but even then I've not found a way. This is part of the reason I made corn.

To better explain my thinking, the issue here of recursion isn't within the config, but rather within the actual implementation. A dynamic string is parsed and split into its elements. For the ironvars within that, a task is spawned to listen to changes. If that ironvar is also now a dynamic string, that gets parsed, and spawns more tasks, which could end disastrously. Taking your initial model...

{
  "ironvar_defaults": {
    "forkbomb": "#forkbomb",
}

...you could quite easily create an infinite loop. Detecting just this simple example would require some re-engineering (the dynamic string doesn't have the context of where it's called from, so it would need to be made aware that it's from an ironvar of name forkbomb). You could also have a recursive loop with multiple steps, which'd need a lot more work to detect and would likely have a measurable impact on parsing.

Arguably this could just be down to the user to not configure it in such a way that it does that, but I think opting to not provide the footgun in the first place is probably the better option.

@JakeStanger commented on GitHub (Jan 25, 2024): I've looked in the past, and integrating Nix as a library into an existing program doesn't seem plausible (at least not without an enormous amount of work). The best case is probably evaluating it to JSON and loading that, but even then I've not found a way. This is part of the reason I made [corn](https://cornlang.dev/). To better explain my thinking, the issue here of recursion isn't within the config, but rather within the actual implementation. A dynamic string is parsed and split into its elements. For the ironvars within that, a task is spawned to listen to changes. If that ironvar is also now a dynamic string, that gets parsed, and spawns more tasks, which could end disastrously. Taking your initial model... ```json { "ironvar_defaults": { "forkbomb": "#forkbomb", } ``` ...you could quite easily create an infinite loop. Detecting just this simple example would require some re-engineering (the dynamic string doesn't have the context of where it's called from, so it would need to be made aware that it's from an ironvar of name `forkbomb`). You could also have a recursive loop with multiple steps, which'd need a lot more work to detect and would likely have a measurable impact on parsing. Arguably this could just be down to the user to not configure it in such a way that it does that, but I think opting to not provide the footgun in the first place is probably the better option.

JakeStanger commented

2026-05-23 03:52:51 +01:00

Author

Owner

@izelnakri commented on GitHub (Jan 26, 2024):

👍 I understand the concern here, and corn is an awesome configuration language btw, loved it! I want to know and even want to write my k8s/helm configurations in it, will eventually look into for how to do it ;)

Regarding your concern, I think it is ok to provide the footgun to the user and adding the detection logic/lookup to the parser code. I think of it as how programming language runtimes throw errors: Uncaught RangeError: Maximum call stack size exceeded would get thrown on infinite loop of cyclical executions in JS for example, so we can throw an exception like this on forkbombs. Of course this isn't urgent, feel free to implement it whenever you see fit & let me know if I'm still missing something in my way of thinking ;)

Something I realized recently, only a bit related, if you're interested:

Actually all this investigation with ironbar made me start to think of a new way to implement the configuration in TypeScript or GJS(Glimmer TypeScript) with a support for Glimmer<->GTK bindings and with support for sh -c and pango markup somehow. Glimmer and maybe the GJS templating language will have a significant impact on frontend development and UI development in my view, seems like it could be implemented to a ironbar or ironbar-like GTK based shell as well eventually.

New GJS templating(will also support JS/TS standard based authoring format): https://github.com/ember-template-imports/ember-template-imports.

A good intro talk in which the developer goes into the most futuristic/minimalistic html templating in TS, if you are interested: https://youtu.be/kjMo0MaJF1Q?si=bvhYfdsV2apyI8Be

@izelnakri commented on GitHub (Jan 26, 2024): :+1: I understand the concern here, and corn is an awesome configuration language btw, loved it! I want to know and even want to write my k8s/helm configurations in it, will eventually look into for how to do it ;) Regarding your concern, I think it is ok to provide the footgun to the user and adding the detection logic/lookup to the parser code. I think of it as how programming language runtimes throw errors: `Uncaught RangeError: Maximum call stack size exceeded` would get thrown on infinite loop of cyclical executions in JS for example, so we can throw an exception like this on forkbombs. Of course this isn't urgent, feel free to implement it whenever you see fit & let me know if I'm still missing something in my way of thinking ;) **Something I realized recently, only a bit related, if you're interested:** Actually all this investigation with ironbar made me start to think of a new way to implement the configuration in TypeScript or GJS(Glimmer TypeScript) with a support for Glimmer<->GTK bindings and with support for `sh -c` and pango markup somehow. Glimmer and maybe the GJS templating language will have a significant impact on frontend development and UI development in my view, seems like it could be implemented to a ironbar or ironbar-like GTK based shell as well eventually. New GJS templating(will also support JS/TS standard based authoring format): https://github.com/ember-template-imports/ember-template-imports. A good intro talk in which the developer goes into the most futuristic/minimalistic html templating in TS, if you are interested: https://youtu.be/kjMo0MaJF1Q?si=bvhYfdsV2apyI8Be

JakeStanger commented

2026-05-23 03:52:51 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jan 29, 2024):

Adding the detection logic into the parser code like that wouldn't be effective, since the values can change at runtime. You'd have to be constantly checking, which I'm not sure how easily possible that would be yet. Definitely something to look into though.

I do have plans to review the custom module in the future and make some under the hood changes, and there have been discussions around implementing some embedded scripting support. I won't rule it out, but I imagine this won't be a templating system as that could be quite a bulky approach to what is only really supposed to be a tool for filling the gaps.

Also just for transparency, it's gonna be a good long while before I get to either issue (ofc open to anybody else picking it up). I'm trying to work through issues in a roughly chronological order, and there's a good few of them to get through!

@JakeStanger commented on GitHub (Jan 29, 2024): Adding the detection logic into the parser code like that wouldn't be effective, since the values can change at runtime. You'd have to be constantly checking, which I'm not sure how easily possible that would be yet. Definitely something to look into though. I do have plans to review the `custom` module in the future and make some under the hood changes, and there have been discussions around implementing some embedded scripting support. I won't rule it out, but I *imagine* this won't be a templating system as that could be quite a bulky approach to what is only really supposed to be a tool for filling the gaps. Also just for transparency, it's gonna be a good long while before I get to either issue (ofc open to anybody else picking it up). I'm trying to work through issues in a roughly chronological order, and there's a good few of them to get through!