Dynamic class names

[izelnakri]

Problem statement: As a user I'd like style my battery module when it's charging(or not) and the battery levels. Same dynamic styling is needed for disk usage, cpu, memory etc.

In waybar I could create a module with different states for different css class name styling.

For example in config.json:

  "disk": {
    "format": "🗄️ {percentage_used}% [{used}]",
    "states": {
      "very-high": 80,
      "high": 60
    },
    "on-click": "tmux kill-session -t disk || alacritty -e tmux new-session -s disk \"zsh -c 'df -h'; zsh\""
  },

This allows me in waybar to style different states via:

#disk.very-high {
  color: @waybar_red_color;
}
#disk.high {
  color: @waybar_orange_color;
}

How can I go about implementing this in ironbar?

One not-so-ideal solution I found is to create different modules with type: custom and has different show_ifs and class attributes. However this solution is very verbose and requires me to create bash scripts(I think?). I'm not even sure how to accomplish this with Pango markup, could you provide an example for this scenario in the documentation?

Basically I think we need:

• a custom states option object & assignments for type: custom and have it documented, or make the class value Dynamic String, even then I'm not sure how to add these classes dynamically on same bash(?) script check?. I'm also not sure how I can create conditionals in Pango markup. I found Pango markup documentation to be insufficient to say the least :sweat_smile:
• If we'd like to keep things as is, with no changes in ironbar. That means the not-so-ideal show_if solution is the only way to go(?). It would be great if we can put a basic example in the documentation for a battery level + charging states custom css classes assignment/change.
• A documented way to declare internal Modules for ironbar.

[JakeStanger]

Thanks for the detailed issue. It sounds like there's a few things nested into one here.

As it stands:

This is not currently achievable natively, and does require some external scripting, but there are ways of doing it with a single script or label module.

Pango markup is akin to HTML, and lets you set some basic attributes on a span. This means it does give you some styling control. For example, <span color="red">hello</span> will work. The entire spec can be found here.

You could output the entire markup from an external script directly (doesn't have to be bash, just needs to write to stdout), or use a label along with the ironvar feature.

For example with ironvars:

{
  "end": [
    {
      "type": "label",
      "label": "<span color'#battery-color'>#battery-percent</span>"
    }
  ]
}

And then you'd have a script call ironbar set battery-color and ironbar set battery-percent.

Alternatively you can use <span color='{{my_script.sh}}'> to call a script directly.

---

The future:

I think there is a clear need for improvement to this, so I'm open to implementing additional functionality. I have never been a big fan of the state model in waybar as it never felt very intuitive to me. It may be that this ends up being the best way to go, but I think this is a long-term goal that requires some planning.

Making the class option a dynamic string feels like a no-brainer to get a quick win. This would still require some external scripting as it stands, but would allow for this to be achieved via the native modules at least.

The documentation requests I'd consider separate to this issue, and there's two there. I'd ask that separate issues are opened for each so they can be individually tracked:

1. More examples for scripting, ironvars and consuming external content in general.
2. Improved code documentation (assuming you're referring to docs around writing your own native modules?). This I've held off intentionally as the internals are far from stable. Once the code-base matures, this will definitely get covered.

[izelnakri]

Hi again @JakeStanger

I tried your two suggestions and there is a pango parser bug with "<span color='#battery-color'>#battery-percent</span>" the parser tries to output the markup before reading the variable inside the color attribute, even when ironvar_defaults declared on the top level, the .textContent area with ironvars work correctly.

Alternatively you can use to call a script directly.

This solution works, and its fantastic, because it allows me to run even deno scripts via #!/usr/bin/env -S deno run --allow-env so sky is the limit ;)

[JakeStanger]

Glad to hear you found a working solution! If you get a chance, could you log the pango bug separately please and I'll investigate that as part of the next release?

[izelnakri]

Added the issue here: https://github.com/JakeStanger/ironbar/issues/418