First off, I'm enjoying our interactions about things conky. Thank you.
ostracized wrote:Now I finally understand why you use pre_exec
. That should almost warrant a bug report to make documentation more clearer in my mind.
${click light on}
And something that should be included in v1.10, IMHO. BTW, the link you used to show that
pre_exec
was depreciated was in Brandon's pre-release of conky version 2.0 - that never really made it to the mainstream. I was hoping by the time v2 came out it would be included (v2 became v1.10). But I'm sure you know that.
Another thing I do not like about v1.10 is: It's slower to load than v1.90
I was just playing around to see what was possible in execp.
Ahhhhh the secret ingredient of life the universe and everything - 'play with', 'test', 'try', 'experiment'
exec - the base
execp - does 'everything' exec does plus 'parsing'
execi - does everything exec does but at specific intervals
execpi - does everything execi does plus the parsing of output
Sometimes I'm pretty lazy about closing tags if the new line is going to change the color anyway. For example:
Code: Select all
${color 0ABFFF}UTC:$alignr${color orange}${utime %T}
${color 0ABFFF}Kernel:$color$alignr$kernel
...it may break convention but the closing color tag isn't needed in the first line here.
Yea, I do that too. I just wanted to point it out. For a reason...
I have some bash scripts here that uses ${execp(i) ...} to run them because there are conky commands in the bash scripts for ${font ..} and ${color ...}. And in some, neither command has a closing counterpart in the script so at first they required:
Code: Select all
${execpi 600 /path/to/bash_script}${font}${color}
until I tweaked them.
A question. Why not use the color0 color1 color2 etc variables above TEXT?
To continue ...
Also - a long time ago I got into the habit of using ${} with all conky commands. The creator of "conkyForecast" demonstrated one day where
$command
can fail in certain instances. So I changed habits. Just a little something to know if you ever run into that situation. I have kicked my butt for years for not documenting exactly what it was.
xkill
and then click on the specific window you want killed? Is that advisable to "kill" conky windows instead of "ending" them, or would it really not matter?
No,
pkill
It's something a friend came up with years ago over on the ubuntu forum:
Code: Select all
pkill -xf "conky -q -c /media/5/Conky/test.conky" &
as long as what is between the " " is
exactly the way you started the conky.
Put it in a bash script:
Code: Select all
#!/bin/bash
pkill -xf "conky -q -c /media/5/Conky/test.conky" &
exit 0
and bob's your uncle. I have that as a command in my OpenBox menu:
R: run E: edit K: Kill | KFC = Kentucky Fried Conky - kills them all!
I'm not a MATE user I use BunsenLabs - Debian8/OpenBox
To
kill
or
end
I don't think it matters ... but looking at the conky man page it's: kill
You Should Know
Conky is generally very good on resources. That said, the more you try to make Conky do, the more resources it is going to consume.
An easy way to force Conky to reload your ~/.conkyrc: "killall -SIGUSR1 conky". Saves you the trouble of having to kill and then restart. You can now also do the same with SIGHUP.
For me:
killall conky && conky
does the same thing as above.
Will continue with next post later - today is my anniversary so I need some wife time.
--- wget stuff looks interesting