I3status-rust: Feature Request: Support configuration through Rust

[Joe23232]

Like DWM is configured in C directly, and how Xmonad is configured in Haskel, I wanted to suggest to have a way to configure i3status-rust using Rust but in a higher level sort of fashion?

[ammgws]

Wouldn't it just end up with you having to fork it so that you could "configure" (aka hardcode all the config options in code) it yourself? You can do that now if you want.

[Joe23232]

But then I would be configuring it in a low level sort of manner. With XMonad and DWM, you are directly dealing with the code but you use a much higher level though in a separate file.

[ammgws]

I've never really understood the appeal of the whole suckless philosophy and I don't see what overall benefits it would bring to the project. Perhaps @atheriel can chime in too.

[Joe23232]

It supposed to give you full power and control and you can avoid using a
scripting language like Lua which can cause some overhead.

On Tue, Jun 23, 2020 at 4:06 PM Jason [e-mail] wrote:

I've never really understood the appeal of the whole suckless philosophy
and I don't see what overall benefits it would bring to the project.
Perhaps @atheriel https://github.com/atheriel can chime in too.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/greshake/i3status-rust/issues/756#issuecomment-647929506,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIKO7INLMHVUO4NUSJTE7P3RYBA7RANCNFSM4OEUOOJQ
.

[GladOSkar]

My 2 cents as to why i think this is not a good idea:

• i3status-rust's config parsing overhead is not very large, and it isn't reloaded very often. A "scripting language like Lua" is not present. The benefits therefore aren't very great.
• rust is known to be slow to compile. In-source configuration only really makes sense for fast-compiling languages (like C and Haskell).
• It would mean a lot of re-architecturing, which is a lot of work.
• suckless' (esp. dwm's) philosophy is intentionally designed to deter newbies. Afaik that's not really something this project is into.

[atheriel]

Whether or not this is a good idea, it's dead in the water without a proposed design to actually discuss. @Joe23232, can you give a mock code example of what you are imaging this configuration would look like? One could of course do this today by modifying block construction in main.rs to build the bar of choice instead of using the configuration; the project is structured as a modular library of blocks already.

Or perhaps what you're after is a way to write certain custom "hooks" for individual blocks, which we don't have an existing configuration path for.

suckless' (esp. dwm's) philosophy is intentionally designed to deter newbies. Afaik that's not really something this project is into

That is my (very cursory) understanding as well, but I don't think anyone is proposing that we promote this approach over our existing strive-to-be-user-friendly configuration and documentation.

As an aside, I expect that the people who want to configure the bar via direct Rust code is approximately equal to the group of enthusiastic users who we want to convert into active contributors by encouraging them to upstream their improvements. Which leads me to ask, what behaviour are you actually looking to change, @Joe23232?

[ammgws]

Closing due to lack of response, please re-open otherwise.