Add a dummy marker module to simplify postprocessing by wrapper scripts about i3status

[Airblader]

It might simplify it, but it's still a crook which IMHO is going in the wrong direction. I think at some point if you want to heavily extend i3status' functionality, you should just stop using i3status and instead use one of the many alternatives like i3blocks. That's the very reason why i3status is a separate project which only interfaces with i3bar – to allow people to write the data tooling to their likings rather than forcing them to use i3status which we want to keep simple.

[memeplex]

I understand your point of view and I think some wrappers out there have gone way too far, so as to let me pondering what is the point of keeping the tiny i3status as an input. But the very documentation of i3status states that filtering is the way to extend it for simple tasks. I already put markers into some module outputs to slightly customize the format. By marking this way I get a good trade off: a wrapper of about 10 locs fine tunes the output of i3status, which still is the workhorse. I don't think this will add significative complexity or locs to i3status and it may reduce complexity and locs for N users out there. I only know that N > 0 though :).

[memeplex]

you want to heavily extend i3status' functionality

It's exactly what I don't want to do. I just want to hook a couple of sed lines to the output.

[Airblader]

I'm not against the idea of having a module for displaying a static text; in fact, I could've sworn this came up before, but I can't find any references to it right now. I agree that a static text module is both extremely easy and would be a really good tradeoff.

[memeplex]

I like the idea of describing it as "a static text module", it sounds more general and less hackish than "a dummy marker module" :).

[stapelberg]

With output_format = i3bar, i3status outputs JSON blocks such as:

[…]
{"name":"ethernet","instance":"eno1","color":"#00FF00","markup":"none","full_text":"E: 10.0.0.76 (1000 Mbit/s)"},
{"name":"volume","instance":"default.Master.0","markup":"none","full_text":"♪: 40%"},
{"name":"load","markup":"none","full_text":"0,63"},
{"name":"time","markup":"none","full_text":"2016-03-30 08:54:55"}
[…]

The name field can be used to identify an i3status module (e.g. ethernet, volume, …) and the instance field is provided whenever the module doesn’t report global status but rather status of a certain item, e.g. of a network interface.

The intention of providing these fields is that you can use them in your filter script to identify and modify individual blocks — no explicit placeholders should be necessary.

Does that satisfy your use-case? If not, why not?

[memeplex]

No, the point is to get additional placeholders to be filled up by the external script, not just identification and modification of existing modules.

[stapelberg]

I’m still not clear on why your use-case is not achievable with the identification of existing modules. You could just add your additional block after one of the existing blocks?

Can you share what you’re actually trying to do please?

[memeplex]

No, because the existing block could be hidden due to its status. A workaround is to set a marker text for the hidden status, but from the perspective of the wrapper writer it's simpler to ensure a placeholder is always there.

I'm adding an email checker module between modules that can be hidden.

[stapelberg]

I’m afraid I still don’t follow. Can you provide the output of i3status and what you’re trying to replace please?