Max Verevkin

I imagine it might be useful for some custom blocks that are hard and/or not efficient to implement as a script and which cannot be merged upstream for some reason....

As an experiment, I'll try splitting `swaystatus` (#430) into two crates - one with all the types, bloks and logic, and the second which will parse the config and run...

> I can start working on this if that's alright! Sure, I'll let you know when I get to the point when at least one block can run, so you...

> maybe it's time to release your fork on crates.io and package that one? https://crates.io/crates/neli-wifi 62a302afb135e52bdb79df7740f7cc87a11154d0

Anyways, you are always free to try this on your fork xD

How about using lua for configuration (nvim way)?

In case it's used only for configuration, the startup might take a little longer, however, looking at neovim, this shouldn't be noticeable. Performance shouldn't be an issue even if lua...

Still, both approaches can coexist.

This is now possible: ```rust use std::sync::Arc; use i3status_rs::config::{BlockConfigEntry, CommonBlockConfig, Config}; use i3status_rs::errors::*; use i3status_rs::escape::CollectEscaped; use i3status_rs::icons::Icons; use i3status_rs::themes::color::Color; use i3status_rs::themes::separator::Separator; use i3status_rs::themes::{ColorOrLink, Theme, ThemeOverrides, ThemeUserConfig}; use i3status_rs::widget::{State, Widget}; use...

Can we just make the "problematic" blocks optional? Users that wish to use them would build from source, just as they would have to build plugins from source. --- >...