added cpu info and usage, loadavg, hackspeed modules

[digitallyserviced]

goodies and more

etc... preview, example configs, etc

[oxodao]

Hi,

Thanks for the contribution !

There is a few thing I'd like you to update if you can:

General:

• snake_case the yaml names / filenames for the new modules except for hackspeed that can stay this way
• remove the commented code as it is not useful
• run gofmt to re-indent everything properly
• avoid to change the example config that are working (e.g. the battery one)
• run go mod tidy to cleanup the not required packages (e.g. gookit's stuff)

cpu_info:

• %cores% doesn't seem to work ? (On my Ryzen 5 2600 it reports 4 core although it's a 6 core CPU) Of course I was not testing on my R5 2600 computer but a laptop that INDEED has 4 cores

load_avg:

• Some parameters are not explained in the docs (unit)
• The running param could be called running_procs (Should be modified in the cpu_usage module too along with blocked => blocked_procs)

hackspeed:

• There is an hardcoded path to a script on your computer so I cannot try this
• This script should be rewritten in go / included in metaprint OR it should depend on a "well-known" tool that can be easily installed separatly and should be told in the docs

For the cpu_usage module, I'm not sure it should keep running, the original goal is to let the user refresh whenever he wants with i3blocks's / tmux's built-in refresh mechanism. Though this is up to debate as I have some other feature that will require it (scrolling text), my original plan was to make a daemon that would talk with metaprint but this might be overkill. It depends on how the parent software handles this. Maybe that's the correct way to do it as if it's not implemented this way, the hackspeed module would be impossible.

By the way, I really like your hackspeed, never thought of this but this is a neat addition !

[digitallyserviced]

Right on, ya I can fix up some of that. As far as the continuous process stuff with the per second usages.

Most bars have no issue with displaying the last line output. Now because the 'usage' types require two readings to get the per second value my thought was rather than having two invocations to get the delta time/value... and because the output is specifically for a per second usage value, why not continuously read/calc/output it continuously? It allows for the user to feel that something is more responsive too.

Otherwise depending on how they are invoked, we would have to read once, write out the values somewhere, with a timestamp, then run again read that data, calc time elapsed, and then display a per second average. I would actually rather not have this output or need to store anything on the filesystem for it to be able to run other than the conifg. Also what if the value wants to be output in more than once place? We wont have to worry about race/atomic write/thread/lock/sync issues.

Also have net usage(up/down speed/s) done locally and gonna clean that up as well. The wifi script I made because the custom feature I think needs to be fleshed out a bit more and actually allow for more customization. A single custom format string in the config should be able to reference multiple command/scripts that can be specified so you can combine shit. Especially since that wifi thing to get ssid, signal, its from multiple locations/utils.

The script for reference if you want to see how I work it and the output...

#!/bin/zsh 
emulate zsh 

local -a wifistr=('🬞🬻' '🬵 ' '🬞 ')
local ssid=$(iwgetid -r)
cat /proc/net/wireless | tail +3 | read iface wstatus link level noise nwid crypt frag retry misc missed
typeset -F 0 sig=${link}

[[ ${sig} -le 100 ]] && { sigchr="${wifistr[1]}"; color=2; }
[[ ${sig} -le 70 ]] && { sigchr="${wifistr[2]}"; color=9; }
[[ ${sig} -lt 50 ]] && { sigchr="${wifistr[3]}"; color=1; }

print -v outstr -f '#[fg=colour0,push-default] %s #[fg=colour%4$d]%02s#[fg=default] (#[fg=colour%4$d,bright,bold]%d%%#[fg=default])#[pop-default]' "${ssid}" "${sigchr}" ${sig} $color

echo ${outstr}

[digitallyserviced]

Also did you test/play with hackspeed? I just remembered you have to add your user to the input group or run it as sudo. I am not sure if I documented that already but figured I would let you know if you have any issues.

[oxodao]

Yes that could be nice too !

I did not try it since it has an hardcoded path to a script: envCmd, ok := NewCmd("/home/chris/.local/bin/keyev", []string{})

[digitallyserviced]

#!/bin/zsh 

stdbuf -i0 -o0 -e0 xkbcli interactive-evdev

make it executable, and either setuid it or add your user to input group... actually you may not need to do that with the xkbcli one.... it was when reading the raw events off /dev/input/evenX that you need the permissions.... which may be necessary to not rely on extra stuff....

sorry it was made into a script to force stdbuf to not make any output buffering occur.
i did quite a bit of playing/research with this and there are other cli commands that can be used, but the most reliable is reading right off the /dev/input/eventX character devices, but they need permission changes.

xkbcli doesn't require any changes, but i think it is X11 only, and without the script can cause output buffering which makes the wpm be nudged towards a 40wpm limit for some reason...

Just a preview of my WIP tmux status bar that i use for my main desktop status bar... with me typing this response... and the hackspeed and other stuff going...

everything on the bar is from metaprint