support output raw content for CommadWidget

[benzwt]

Don't call format_string if the command_xxx_format doesn't contains style syntax. This will let the external command to take the responsibly for the output of the content. For example, this feature let conky output its result along with the raw color codes.

[benzwt]

sample images

info from left to right:

• up time
• disk usage
• load average
• memory usage
• battery percentage

my config files

• zjstatus.kdl
• conky.conf

conky

• I use conky-1.19.6
• I built conky with

  cmake -DBUILD_X11=OFF -DBUILD_WAYLAND=OFF

to make it even more lightweight, because I don't need graphic support.

• If you prefer to use package-manager, it is advice to check whether your disto have conky-cli

[dj95]

Hey @benzwt

thank you so much for the contribution! It's really awesome to see conky within zjstatus! Is it ok, if I put your config and screenshot to the examples section?

This merge request inspired me for another idea for the command widget: specifying the rendering mode (static, dynamic or raw).

Thanks a lot and enjoy the holidays.

[benzwt]

@dj95 Just go ahead to put my config to examples/. I am conceiving to put every static data into cache, since the kdl config is read only once. Such thing only to be processed only once. This should make the render go faster. Let's open an issue or discussion to talk about it. Thanks!

[dj95]

Thanks.

What exactly do you want to cache? I've implemented the render modes a few hours ago.

[dj95]

Actually I implemented zjstatus from the beginning, such that everything from the config is parsed on plugin start and remains in memory. It only prints the data with the format on re-rendering the bar. Therefore it should be mostly cached and out of the way except for the dynamic mode in the command widget. However, I don't think this one can be cached properly.

[benzwt]

Actually I implemented zjstatus from the beginning, such that everything from the config is parsed on plugin start and remains in memory. It only prints the data with the format on re-rendering the bar. Therefore it should be mostly cached and out of the way except for the dynamic mode in the command widget. However, I don't think this one can be cached properly.

@dj95 I have just pulled and sync with the HEAD. I saw your commits, you are vigorous ! dynamic render mode is cool !

About the cache I mentioned earlier is a little bit aggressive. Instead of caching Colorinfo in FormattedPart, I would like to try to cache the raw ansi color sequences, instead. Just a plan without any confidence that whether it will help.

[dj95]

With the latest commit on the main branch only widgets, that receive new data via an event, are re-rendered. Everything else is now cached - even with ansi sequences etc. Basically the result of the widget with the current state.

This allowed me to push the rendering time in the benchmarks from 20 microseconds to 3.5 microseconds (+ time for the widget that needs an update) on my machine (MBP with M1 Pro). Thanks a lot for the input! It really helps me to optimise zjstatus further!

[benzwt]

This allowed me to push the rendering time in the benchmarks from 20 microseconds to 3.5 microseconds

@dj95 Which benchmark case were you mention about ? I have added some experimental code, I want to benchmark against it. thanks!

[dj95]

@benzwt I used the benchmark for render_bar. You can run benchmarks with just bench, when you have just installed.

Please keep in mind that these numbers are heavily depending on your hardware and system configuration. So these numbers are only valid for my setup on my MBP with M1Pro and nix-darwin. For a good result you should benchmark zjstatus without and with your changes to get a comparable value.