This is just a quick brainstorm I wrote out about making labels, ramps etc. more flexible. sdk on IRC wanted it converted to an issue so they can track it.

Don't restrict what labels, ramps, etc a user can specify

A user should be able to set

format = <label-abc> <ramp-abc>
format-connected = <ramp-xyz>

label-abc = Text
ramp-abc-0 = A
ramp-abc-1 = B
ramp-abc-2 = C

ramp-xyz-0 = X
ramp-xyz-1 = Y
ramp-xyz-2 = Z

And polybar will automatically deduce what is a label and what is a ramp and load them from the config accordingly.

The percentage a ramp or progressbar is tied to in a certain module should be obvious, where it is not, we should allow users to specify

This would make lots of code handling label loading in modules redundant. The customizability is then mainly constrained by what formats we allow.

This approach may prove harder to integrate with dynamic labels like label-mode in the bspwm module that gets replaced by other labels depending on the state.

We should then also allow the user to use all tokens in all labels, ramps etc.

EDIT:

See #1968 for a specific usecase where the current system is limiting expressiveness.

EDIT:

#2087 also has a nice use-case that would be enabled by this: Ramps for format-muted in the volume modules.

EDIT:

For tags (e.g. <label-...>) with special functionality (e.g. use a different label depending on the state or have actions associated with them) we could introduce a set of special names per module that, when used, automatically use that functionality.

For example for the <label-state> tag in the workspace modules, the name would be state and if <label-state>, <ramp-state>, <animation-state>, or <bar-state> is seen in the format, the module will automatically select for example <animation-urgent> if <animation-state> is specified and the workspace has the urgent flag set. It would also automatically get the right click commands.

This should probably be done incrementally by first only implementing support for drawtypes that don't depend on a percentage (the xwindow module is a good candidate here) and building from there. It might be a good idea to create a new abstract module class that modules that use this new system use with the goal of migrating all modules to this new system as it grows more capable.