My modified version of MX-MyConky [Solved]

[asqwerth]

The $endif must be placed not immediately after the "if" statement, but after the whole segment you need to change/adjust for the 16-core scenario.

That way, if the if statement is not applicable to your system, the conky will ignore that section between the if and the endif.

[siamhie]

The $endif must be placed not immediately after the "if" statement, but after the whole segment you need to change/adjust for the 16-core scenario.

That way, if the if statement is not applicable to your system, the conky will ignore that section between the if and the endif.

@asqwerth Do you mean like this. I don't code so this is all new to me.

Code: Select all

#-----------------------CPU-----------------------
${offset 10}${font Good Times:size=12}${color Tan1}CPU ${color}${hr 2}${font}
${alignc}${font}${color}${execi 86400 grep -m1 -oP '^model name\s+:\s\K(.*)' /proc/cpuinfo}
${alignc}${color}Temperature: ${if_existing /sys/class/hwmon/hwmon0/temp1_input}${eval ${hwmon 0 temp 1}}${else}${if_existing /sys/class/hwmon/hwmon1/temp1_input}${eval ${hwmon 1 temp 1}}${endif}${endif}°C
${if_match ${execi 86400 grep -m1 -oP '^cpu cores\s+:\s\K(.*)' /proc/cpuinfo} == 24}
CPU1 ${goto 180} ${cpu cpu1}% ${lua gradbar {4, 190, "${cpu cpu1}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 1} ${goto 355}MHz
${voffset 10}CPU2 ${goto 180} ${cpu cpu2}% ${lua gradbar {4, 217, "${cpu cpu2}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 2} ${goto 355}MHz
${voffset 10}CPU3 ${goto 180} ${cpu cpu3}% ${lua gradbar {4, 245, "${cpu cpu3}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 3} ${goto 355}MHz
${voffset 10}CPU4 ${goto 180} ${cpu cpu4}% ${lua gradbar {4, 272, "${cpu cpu4}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 4} ${goto 355}MHz
${voffset 10}CPU5 ${goto 180} ${cpu cpu5}% ${lua gradbar {4, 302, "${cpu cpu5}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 5} ${goto 355}MHz
${voffset 10}CPU6 ${goto 180} ${cpu cpu6}% ${lua gradbar {4, 330, "${cpu cpu6}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 6} ${goto 355}MHz
${voffset 10}CPU7 ${goto 180} ${cpu cpu7}% ${lua gradbar {4, 358, "${cpu cpu7}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 7} ${goto 355}MHz
${voffset 10}CPU8 ${goto 180} ${cpu cpu8}% ${lua gradbar {4, 386, "${cpu cpu8}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 8} ${goto 355}MHz
${voffset 10}CPU9 ${goto 180} ${cpu cpu9}% ${lua gradbar {4, 414, "${cpu cpu9}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 9} ${goto 355}MHz
${voffset 10}CPU10 ${goto 180} ${cpu cpu10}% ${lua gradbar {4, 442, "${cpu cpu10}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 10} ${goto 355}MHz
${voffset 10}CPU11 ${goto 180} ${cpu cpu11}% ${lua gradbar {4, 470, "${cpu cpu11}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 11} ${goto 355}MHz
${voffset 10}CPU12 ${goto 180} ${cpu cpu12}% ${lua gradbar {4, 498, "${cpu cpu12}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 12} ${goto 355}MHz
${voffset 10}CPU13 ${goto 180} ${cpu cpu13}% ${lua gradbar {4, 526, "${cpu cpu13}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 13} ${goto 355}MHz
${voffset 10}CPU14 ${goto 180} ${cpu cpu14}% ${lua gradbar {4, 554, "${cpu cpu14}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 14} ${goto 355}MHz
${voffset 10}CPU15 ${goto 180} ${cpu cpu15}% ${lua gradbar {4, 582, "${cpu cpu15}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 15} ${goto 355}MHz
${voffset 10}CPU16 ${goto 180} ${cpu cpu16}% ${lua gradbar {4, 610, "${cpu cpu16}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 16} ${goto 355}MHz
${voffset 10}CPU17 ${goto 180} ${cpu cpu17}% ${lua gradbar {4, 638, "${cpu cpu17}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 17} ${goto 355}MHz
${voffset 10}CPU18 ${goto 180} ${cpu cpu18}% ${lua gradbar {4, 666, "${cpu cpu18}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 18} ${goto 355}MHz
${voffset 10}CPU19 ${goto 180} ${cpu cpu19}% ${lua gradbar {4, 694, "${cpu cpu19}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 19} ${goto 355}MHz
${voffset 10}CPU20 ${goto 180} ${cpu cpu20}% ${lua gradbar {4, 722, "${cpu cpu20}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 20} ${goto 355}MHz
${voffset 10}CPU21 ${goto 180} ${cpu cpu21}% ${lua gradbar {4, 750, "${cpu cpu21}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 21} ${goto 355}MHz
${voffset 10}CPU22 ${goto 180} ${cpu cpu22}% ${lua gradbar {4, 778, "${cpu cpu22}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 22} ${goto 355}MHz
${voffset 10}CPU23 ${goto 180} ${cpu cpu23}% ${lua gradbar {4, 806, "${cpu cpu23}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 23} ${goto 355}MHz
${voffset 10}CPU24 ${goto 180} ${cpu cpu24}% ${lua gradbar {4, 834, "${cpu cpu24}", 100, 125, 2, 10, 1, 0xFFFFFF, 0.25, 0x00FF00, 1, 0xFFFF00, 1, 0xFF0000, 1}}${goto 310}${color}${freq 24} ${goto 355}MHz${endif}

[asqwerth]

In my mega-multicore conky version, I placed the ${endif} at the end of the memory section and memperc gradbar for every different scenario. That's because for every different number of cores (and thus, different no of gradbars), the positioning of the memperc bar is also different and has to be established separately for each scenario.

Thus, the structure of the conky for this part should be:

1. is the no of cores = X number? If yes, run the whole section up to $endif, namely display the cpu and memory details and draw the lua gradbars for the number of cores and position the memory gradbar accordingly. If no, skip the whole section bracketed by if_match and endif, and go to the next "if_match" section.

2. the last fallback scenario, that I haven't been able to do because I don't have enough script-fu, is a scenario where, if no of cores don't match any of the numbers already addressed in the above other scenarios, simply display the average cpu0 load gradbar, and position memperc bar accordingly. This part will follow roughly the lines of the current default MX-MySysInfo conky, except the position of the memperc bar should be corrected per the other thread I previously started.

If the fallback scenario does not exist and the user's no of cores is not one of those included, the program will skip all the if_match...endif parts because the conditions in all the scenarios aren't satisfied, and then just display the Processes and Networks sections of the conky. You would get a very truncated conky.


PS. I don't really code either.

[jeffreyC]

@asqwerth It runs but I'm still facing fuzzy text when I restart the fluxbox desktop.

In my experience having two conkies running in the same place at the same time will cause that, it is why most conky start scripts begin with killall conky.
Restarting the Fluxbox desktop is starting conky without killing the existing conky.

[siamhie]

@asqwerth It runs but I'm still facing fuzzy text when I restart the fluxbox desktop.

In my experience having two conkies running in the same place at the same time will cause that, it is why most conky start scripts begin with killall conky.
Restarting the Fluxbox desktop is starting conky without killing the existing conky.

Doesn't explain why other conky's I've written myself don't display this issue. In fact, I swapped out the conky.conf section for a known working one I built
and I don't get the fuzzy look when restarting the fluxbox desktop. I think there is possibly old or changed variables in the original conky. I even get the
fuzzy look using MX-ManyRoads conky when restarting the desktop.

This is what happens when you select restart from the menu in fluxbox.

Code: Select all

Restart ([restart] (Restart))

Restart the whole darn thing. This starts a completely new fluxbox
process, rereads files and redraws all graphical elements. Running
applications will remain open, however, and restored to the same
workspaces they were previously in once fluxbox returns.

[AVLinux]

FWIW, granted I never got it up and running properly on my system but something very weird I noticed was the parts of it that would run looked clear on the Desktop but when I took a screenshot the shot was all garbled looking.. I chalked this up to nVidia purgatory but maybe its something else..?

[ceeslans]

@asqwerth It runs but I'm still facing fuzzy text when I restart the fluxbox desktop.

In my experience having two conkies running in the same place at the same time will cause that, it is why most conky start scripts begin with killall conky.
Restarting the Fluxbox desktop is starting conky without killing the existing conky.

Doesn't explain why other conky's I've written myself don't display this issue. In fact, I swapped out the conky.conf section for a known working one I built
and I don't get the fuzzy look when restarting the fluxbox desktop. I think there is possibly old or changed variables in the original conky. I even get the
fuzzy look using MX-ManyRoads conky when restarting the desktop.

Afaik, the own_window_transparent='true' and own_window_argb_visual='true' settings don't play nice with each other when in the same config.
I guess that MX-MyConky requires own_window_argb_visual='true' to be set (haven't checked it myself tho')?. If so, suggest you disable own_window_transparent='true' in conky's lua section.
Another issue I ran into myself a few times with conkys, which only have own_window_transparent='true' set --> I experience exactly the same behavior you described about fuzzy fonts and overwritten data, i.e immediately after a [fluxbox-remote restart] command is executed. It doesn't happen after [fluxbox-remote reconfig]...
Perhaps you can check this from your end too

[fehlix]

In my experience having two conkies running in the same place at the same time will cause that, it is why most conky start scripts begin with killall conky.
Restarting the Fluxbox desktop is starting conky without killing the existing conky.

Doesn't explain why other conky's I've written myself don't display this issue. In fact, I swapped out the conky.conf section for a known working one I built
and I don't get the fuzzy look when restarting the fluxbox desktop. I think there is possibly old or changed variables in the original conky. I even get the
fuzzy look using MX-ManyRoads conky when restarting the desktop.

Afaik, the own_window_transparent='true' and own_window_argb_visual='true' settings don't play nice with each other when in the same config.
I guess that MX-MyConky requires own_window_argb_visual='true' to be set (haven't checked it myself tho')?.
If so, suggest you disable own_window_transparent='true' in conky's lua section.

On most MX conkys with set when fluxbox was detected this:

Code: Select all

return_code = os.execute('pidof -q fluxbox')
if _VERSION == 'Lua 5.1' and math.floor(return_code/256) == 0 or
   _VERSION ~= 'Lua 5.1' and return_code then
   conky.config.own_window_transparent = true
   conky.config.own_window_argb_visual = false
end

Another issue I ran into myself a few times with conkys, which only have own_window_transparent='true' set --> I experience exactly the same behavior you described about fuzzy fonts and overwritten data, i.e immediately after a [fluxbox-remote restart] command is executed. It doesn't happen after [fluxbox-remote reconfig]...
Perhaps you can check this from your end too

On fluxbox restart/refresh, we combine this normaly with reload/refresh of the conky, by sending a USR1 signal,
which avoids the blurring conky effect, using something like:

Code: Select all

killall  -SIGUSR1 conky

[siamhie]

I experience the same situation with the MX-ManyRoads cpu, memory and disc files that have lua bars.

MX-MR.jpg

Code: Select all

killall  -SIGUSR1 conky

Thanks. Added that to my menu for the time being.

Code: Select all

[exec] (Restart Conky) {killall -SIGUSR1 conky}

[siamhie]

@AVLinux Try this one. It's my first 24 core conky.
Unzip into your conky directory and read the ReadMe file for CPU temp instructions.

MX-MultiCore.zip