@juliancoffee The module state machines are still kind of a vague idea. I toyed around with it a bit polybar/polybar#1963, but I realized that it's better to separate the state of the module itself (running, stopped, etc) from the state of the thing the module is observing (cpu load, temperature, etc), let's call this the data state.
Right now what I'm envisioning is that the module state is managed externally (for example by the controller) and modules are started, stopped, restarted as needed.
The data state is managed by the module base class, each module implementation only needs to declare which states exist, signal events, and define which transitions happen for which event. The base class then determines which format should be used.
This ties in a bit with my polybar/polybar#1752 about custom label names since removing the restriction of which label names are allowed makes it easier for the base class to manage the labels, ramps, etc. in each format.
I think the two ideas can be implemented completely independently. I also think that adding only the data state machines (without arbitrary label names) is already a huge task, so it's probably a good idea to migrate modules one by one to a new system. We could do this for example by subclassing the module class and using that new class as the base for all modules in the new system. Once all modules are migrated, we can merge this subclass back into the module class.
So the first step would be to create this new base class and migrate a single module, a simple one like the cpu module.
@juliancoffee That is the way it is currently done, yes. However, each module implementation has to manage its own state, the base class does not help here. Looking at the code again, it may not be feasible to actually move more of the state managing to the base class because right now each format has a different set of labels, ramps and progressbars associated with it. Maybe it would make more sense to first implement the custom label names and only afterwards generalize the state machine.
The reason we want to move the state machine to the base class, is because adding a new format-warn or format-critical to each module adds more or less the same code to every module. This much code duplication is just bloat and will only make it harder to refactor a module. That's why we want to make it easier to just add a new format without having to add too much code. Having no restriction on what labels, ramps, etc. can be in a specific format make this a lot easier.
base.inl in the get_output function. That's probably where this effort needs to start.
idk I if bugged it to get the text to append on the left side but it works. I want to have the tray attached left instead of floating off a little.
padding-left set in your bar section?
bspc subscribe report. HDMI-1 is getting desktops assigned alright - I can switch 1 to 5 but the polybar shows 6 - 0. Desktops on the eDP-1, are created fine as well - I am able to use desktops 6-0. But with eDP-1, there's only weird margin where polybar should be.
label-monitor = %name% and format = <label-state> <label-monitor> to the bspwm module and try again. I suspect that the bar that displays 6-0 is actually the bar that was started on eDP-1. Once polybar is started it stays where it is, in your case the bar on eDP-1 is at 0x0 when you connect the HDMI monitor, the bar started for eDP-1 stays at 0x0, but now 0x0 is the top-left corner of your HDMI monitor.
screenchange-reload = true into the [settings] section. This way, polybar restarts for you
PATH variable (and probably others) are different. So whatever sets those variable to include conda, probably runs after the wm startup.
