Compare commits
No commits in common. "a20777be37d328a79b21ad963b5c6558efbbc5a3" and "7fb4d8a8b062326fe97d1c5c026e5467fac02c3e" have entirely different histories.
a20777be37
...
7fb4d8a8b0
38
README.md
38
README.md
@ -4,16 +4,34 @@ root window (mostly I only see one window taking up the entire screen, with a
|
||||
dmenu at the top, and another dmenu at the bottom that runs conky). I run conky
|
||||
in CLI mode only, and that's good enough for me.
|
||||
|
||||
I pipe the output of conky through dmenu, which upates every second. I also
|
||||
have custom formatting functions (see scripts.lua in this repository). This
|
||||
ensures the output of conky has the same length, even if certain fields within
|
||||
the string change. This is especially useful for the network bandwidth output,
|
||||
which otherwise change length every two seconds as the bandwidth usage
|
||||
I pipe the output of conky through dmenu, which upates every two seconds. I
|
||||
also have custom formatting functions (see scripts.lua in this repository).
|
||||
This ensures the output of conky has the same length, even if certain fields
|
||||
within the string change. This is especially useful for the network bandwidth
|
||||
output, which otherwise change length every two seconds as the bandwidth usage
|
||||
fluctuates between bytes (B), Kilobytes (KiB), and Megabytes (MiB).
|
||||
|
||||
I have implemented `conky_printf`, a generalized function for printing conky
|
||||
data to the output string. It needs more testing, as I'm sure there are edge
|
||||
cases where it doesn't work properly.
|
||||
TODO: My formatting function needs to be generalized. Essentially, I'm
|
||||
creating a conky-specific printf function. Right now, it's split into two
|
||||
functions, with calls to the Lua string.format function. One function takes
|
||||
only one format specifier, and the other takes two.
|
||||
|
||||
TODO: Add color to the conky output! That will take if statments, and text
|
||||
for dmenu to consume.
|
||||
The `fmt()` function takes the format string, and expects a single numerical
|
||||
second argument. If the format string contains any format specifiers (see `man
|
||||
sprintf` for details) that aren't numbers (e.g. `%s` for strings), fmt() will
|
||||
fail with an error. I use this for the percentages of RAM, Swap, and CPU in
|
||||
use.
|
||||
|
||||
The `fmt2()` function takes the format string, and expects two string arguments.
|
||||
It is not necessarily an error if either or both of the arguments are numbers,
|
||||
they will be cast to strings. I use this function to format the bandwidth
|
||||
("Net:") display in conky, so the length of this segment doesn't shift around
|
||||
(the Unicode arrow icons for up and down bandwidth stay in the same place).
|
||||
|
||||
Ideally these two functions would be combined into a `"conky_printf` function,
|
||||
that could take an arbitrary format string with any number of format
|
||||
specifiers, with the requisite number of numerical or string arguments. I know
|
||||
how to do this with the `...`/`arg`/`unpack(arg)` table specification in Lua,
|
||||
but numeric specifiers need to convert any strings passed to the function to
|
||||
numeric values instead of strings. This is the challenging part, but should be
|
||||
doable.
|
||||
|
@ -39,15 +39,11 @@ conky.config = {
|
||||
|
||||
conky.text =
|
||||
[[\
|
||||
${lua_parse printf %-20s ${nodename_short}} \
|
||||
RAM:${lua_parse printf %3.0f%% ${memperc}} \
|
||||
Swap:${lua_parse printf %3.0f%% ${swapperc}} \
|
||||
CPU:${lua_parse printf %3.0f%% ${cpu cpu0}} \
|
||||
/ ${lua_parse printf %10s/%10s ${fs_used /} ${fs_size /}} \
|
||||
/ ${fs_used /}/${fs_size /} \
|
||||
${loadavg} \
|
||||
${lua_parse printf %-20s ${top name 1}} \
|
||||
${lua_parse printf %8d ${top pid 1}} \
|
||||
${lua_parse printf %3.2f ${top cpu 1}} \
|
||||
${lua_parse printf %3.2f ${top mem 1}} \
|
||||
${top name 1} ${top pid 1} ${top cpu 1} ${top mem 1} \
|
||||
Net: ${lua_parse printf %10s▲%10s▼ ${upspeed wlp4s0} ${downspeed wlp4s0}} \
|
||||
]];
|
||||
|
Loading…
Reference in New Issue
Block a user