my conky circle theme

[fehlix]

but maybe you consider to move that "setup" logic into
a lua-function e.g. named like circle_setup(), where you re-formulate the python-logic into this lua-function,
and populate a "global" setup-table.

I thought already doing this.
conky.arcs.lua starts with:

Code: Select all

cfg = require 'config'
settings = cfg.setup()

... and generated config.lua looks like this:

Code: Select all

local config = {}

function config.setup()
  return {
  ...
  }
end

return config

and function conky_main then uses global table "settings"

OK, thanks. I was mentioning in case you want to avoid the install-python script,
to put all the detection work into a one-time running function,
you could then probably consider to use "lua_startup_hook".
Currently the global setup table is populated during lua_load,
which is fine, b/c that's a "static" table, which was genrated externaly with the python-script. But as I understood, they
introduced the "lua_startup_hook" to provide one spot, where all heavy loading/detection stuff can be run.

Maybe explain this issue, so somone can follow.

may be I don't understand the point, you're leading me to.

Code: Select all

$ cat /sys/class/hwmon/hwmon0/name
nvme

which is the same for all nvme-sensors.

... and

Code: Select all

$ ll /sys/class/hwmon/hwmon0/device/
insgesamt 0
drwxr-xr-x 10 root root    0  3. Feb 14:08 nvme1n1
...

so from device's subdirectory I take the "real" name of the sensor

The point I mentioned was to use hwmon calls instead of lua-read-temp.
Ahh, so the "issue" you mentioned was to combine the device "name" for those sensor types like "nvme".
and display the device name. OK, now I understand.
Also I tested you latest one, so seems you prefer to show temp with decimal places, which show here up to three decimals,
so you now can watch the temps in milleCentis. I could only avoid those decimals by letting conky get the temp with a ${hwmon ...} call.
Performance wise, probably not a big difference using lua-call or a hwmon-call, but still assume the compiled in hwmon call
is a bit faster then the lua-read-temp call.
Maybe final note: I really like the whole thing, but remember, MX is providing snapshot feature, and creation of
LiveUSBs, and it would be really nice if your conky would include a internal setup, instead requiring re-installation/re-setup,
when running on different systems. b/c when you move around onto another system,
with eg. LiveUSB or a personal Snapshot-ISO booted with Ventoy or a normally installed
on external removal drives. Or even only on internal installed system, I had the effect
the nvme's got different names depending whether I boot different different kernel. Can't remember
which one caused it. I was testing different things with both sysVinit and systemd and differernt liquorix and normal debian kernels,
where suddenly the nvme swapped the names.
And as you current conky is only prepared for the current running system after a re-setup/re-install.
Actually this would also be a show stopper for potentially getting this conky as it is currently setup, into a the MX collection of offered conky's.
So all is prepared by you. Great! May be you can find a way to move the python-setup stuff into the lua-setup-run-at-start thing.
Thanks

[django013]

I really like the whole thing, but remember, MX is providing snapshot feature, and creation of
LiveUSBs, and it would be really nice if your conky would include a internal setup, instead requiring re-installation/re-setup,
when running on different systems.

Thanks for the food for thought!

What I did was to learn both languages. But now I'll gonna follow your advices and move the python stuff to lua.
Might be a challenge for me, but I like that

[django013]

Hi,

I made the setup with lua working (without conky) and I'm working to put all together.
I failed to handle font files following your hints:

In addition if you would keep the fonts e.g within the sub folder of the conky ".conky/MX-Circles/fonts" you could now refresh the fontconfig cache with the setup-function e.g with something like "fc-cache -r ~/.conky/MX-Circles/fonts",
which would only be needed to run when those fonts are not already available with font-config cache, e.g. which you can check with "fc-list | grep fontname".

I removed the font files from system directories and executed the "fc-cache" command, which took a while before return, but it did not add the font files to the system cache. "fc-list" does not show the font files from subdirectory "fonts".

[fehlix]

Hi,

I made the setup with lua working (without conky) and I'm working to put all together.

Great.

I failed to handle font files following your hints:

In addition if you would keep the fonts e.g within the sub folder of the conky ".conky/MX-Circles/fonts" you could now refresh the fontconfig cache with the setup-function e.g with something like "fc-cache -r ~/.conky/MX-Circles/fonts",
which would only be needed to run when those fonts are not already available with font-config cache, e.g. which you can check with "fc-list | grep fontname".

I removed the font files from system directories and executed the "fc-cache" command, which took a while before return, but it did not add the font files to the system cache. "fc-list" does not show the font files from subdirectory "fonts".

Yes, I was probably misleading. The simplest copy the font into the standard-location for user-installed fonts
according to "XDG Base Directory Specification" :
from "~/.conky/MX-Cirlces" (i.e. conky-base-dir/fonts) to "~/.local/share/fonts", needs to be created if not exists.
The fonts cache will be generated automatically. Not sure about the timing, but background fonts generation is very fast
Either check files already exist, or double check with fc-list | grep, or check the ~/.cache/fontconfig.
and "fc-cache ~/.local/share/fonts/" if needed, so no need to regnerate, if exist already.

[django013]

The simplest copy the font into the standard-location for user-installed fonts
according to "XDG Base Directory Specification" :
from "~/.conky/MX-Cirlces" (i.e. conky-base-dir/fonts) to "~/.local/share/fonts", needs to be created if not exists.

Well, that copy-action leads to require an installer, as every font-directory is owned by root.
I read in /etc/fonts/fonts.conf, that font- and fontconfig-directories from users home will be removed, so not the best place.

As conky is default on mx-systems, how about to add a directory entry for fontconfig to search for fonts in ~/.conky and subdirectories?
Using my installer it is no issue to copy font files to system location, but with implicit setup from running conky I can't use sudo for it.

So what is your recomendation?

P.S. don't know, whether you know it: lua_startup_hook is executed after conky_main.
So for me there's no reason to use startup-hook

[fehlix]

The simplest copy the font into the standard-location for user-installed fonts
according to "XDG Base Directory Specification" :
from "~/.conky/MX-Cirlces" (i.e. conky-base-dir/fonts) to "~/.local/share/fonts", needs to be created if not exists.

Well, that copy-action leads to require an installer, as every font-directory is owned by root.
I read in /etc/fonts/fonts.conf, that font- and fontconfig-directories from users home will be removed, so not the best place.

As conky is default on mx-systems, how about to add a directory entry for fontconfig to search for fonts in ~/.conky and subdirectories?

Using my installer it is no issue to copy font files to system location, but with implicit setup from running conky I can't use sudo for it.

So what is your recomendation?

You probably referring to the legacy fonts directories ~/.fontconfig ~/.fonts, which are since a long time "marked" as to be removed,
as mention in /etc/fonts/fonts.conf, like this:

Code: Select all

    <dir prefix="xdg">fonts</dir>
    <!-- the following element will be removed in the future -->
    <dir>~/.fonts</dir>

and

Code: Select all

    <cachedir prefix="xdg">fontconfig</cachedir>
    <!-- the following element will be removed in the future -->
    <cachedir>~/.fontconfig</cachedir>

below the two xdg-lines. Where the line

Code: Select all

	<dir prefix="xdg">fonts</dir>

referes to
$XDG_DATA_HOME/fonts, which defauts to $HOME/.local/share/fonts
and the line

Code: Select all

	<cachedir prefix="xdg">fontconfig</cachedir>

referes to
$XDG_CACHE_HOME/fontconfig, which defauts to $HOME/.cache/fontconfig
So, yes, don't use legacy directories, but only the default xdg-directories, which are
used by fontconfig.

P.S. don't know, whether you know it: lua_startup_hook is executed after conky_main.
So for me there's no reason to use startup-hook

Not sure I understand or maybe I misunderstand what you are saying.
Whithin conky.config you would have something like this:

Code: Select all

conky.confg = {
...
	lua_load = './conky.arcs.lua',
	lua_startup_hook = "conky_setup",
	lua_draw_hook_post = conky_main'
}

also you don't need or you can avoid a the "require", you corrently are using:

Code: Select all

cfg = require 'config'
settings = cfg.setup()

and load both script with lua_load this way:

Code: Select all

	lua_load = "conky.arcs.lua config.lua",

So you would have only loaded the function, defined with both scripts,
with no execution of any function.
The next would be the lua_startup_hook , where you call a conky_setup function,
which would do one time only populatimg the gobal settings table.
And finally with lua_draw_hook_post the function conky_main will be called
by Conky through each iteration after drawing to the window, where the
settings table will be read.

For reference, what "man conky" mentions about lua_load and the hooks:

Code: Select all

lua_load
      Loads the Lua scripts separated by spaces.

lua_startup_hook function_name [`function arguments']
      This  function, if defined, will be called by Conky at startup
      or when the configuration is reloaded.  Use this hook to  ini‐
      tialize  values, or for any run-once applications.  Conky puts
      `conky_' in front of function_name to prevent accidental calls
      to the wrong function unless you place `conky_' in front of it
      yourself.

and pre and post hooks:

Code: Select all

lua_draw_hook_post function_name [`function arguments']
      This  function,  if  defined,  will be called by Conky through
      each iteration after drawing to the window.  Requires  X  sup‐
      port.   Takes any number of optional arguments.  Use this hook
      for drawing things on top of what  Conky  draws.   Conky  puts
      `conky_' in front of function_name to prevent accidental calls
      to the wrong function unless you place `conky_' in front of it
      yourself.

lua_draw_hook_pre function_name [`function arguments']
      This  function,  if  defined,  will be called by Conky through
      each iteration before drawing to the window.  Requires X  sup‐
      port.   Takes any number of optional arguments.  Use this hook
      for drawing things on top of what  Conky  draws.   Conky  puts
      `conky_' in front of function_name to prevent accidental calls
      to the wrong function unless you place `conky_' in front of it
      yourself.

[django013]

Hi,

my XDG_DATA was screwed up by flatpack

Code: Select all

XDG_DATA_DIRS=/home/[user]/.local/share/flatpak/exports/share
              /var/lib/flatpak/exports/share
              /usr/local/share
              /usr/share

... and I don't have XDG_DATA_HOME or XDG_CACHE_HOME

I'll check fontconfig again.

I tested conky with

Code: Select all

conky.confg = {
...
	lua_load = './conky.arcs.lua',
	lua_startup_hook = 'setup',
	lua_draw_hook_post = 'main'
}

In lua-code I added a simple oneliner to output some text (kindof logging) from each function.
Logfile showed, that conky_main will be called first.
After terminating first call of conky_main conky_setup will be called.
So that's rubbish.

another conky issue: conky uses german locale on "tonumber(x)" calls, which of cause breaks generated lua sources
... but I found a workaround

Well, I did it my way
... and it works. - I used the old font-directory ~/.fonts so far
I extended the script to support smaller hardware too.
Small hardware will result in this output (without manual polishing):

MX-Circles0.jpg

and bigger hardware will result in this output (without manual polishing):

MX-Circles1.jpg

I you like to give it a try:
rename attachment to *.tar.xz and unpack it to ~/.conky
Then issue a "conky -c MX-Circles"
When the circles appear, hit ^C and restart conky as usual

[fehlix]

Hi,

my XDG_DATA was screwed up by flatpack

Code: Select all

XDG_DATA_DIRS=/home/[user]/.local/share/flatpak/exports/share
              /var/lib/flatpak/exports/share
              /usr/local/share
              /usr/share

... and I don't have XDG_DATA_HOME or XDG_CACHE_HOME

I'll check fontconfig again.

I tested conky with

Code: Select all

conky.confg = {
...
	lua_load = './conky.arcs.lua',
	lua_startup_hook = 'setup',
	lua_draw_hook_post = 'main'
}

In lua-code I added a simple oneliner to output some text (kindof logging) from each function.
Logfile showed, that conky_main will be called first.
After terminating first call of conky_main conky_setup will be called.
So that's rubbish.

another conky issue: conky uses german locale on "tonumber(x)" calls, which of cause breaks generated lua sources
... but I found a workaround

Well, I did it my way
... and it works. - I used the old font-directory ~/.fonts so far
I extended the script to support smaller hardware too.
Small hardware will result in this output (without manual polishing):
MX-Circles0.jpg

and bigger hardware will result in this output (without manual polishing):
MX-Circles1.jpg

I you like to give it a try:
rename attachment to *.tar.xz and unpack it to ~/.conky
Then issue a "conky -c MX-Circles"
When the circles appear, hit ^C and restart conky as usual

Thanks, will look into this over the weekend ...
(Yes, XDG_DATA_HOME or XDG_CACHE_HOME, if not set, they are used by the system in away as if they would been set to the default, as already mentioned.)

Note:You can attach zip-files, e.g by wrapping/putting the current archive-files again into a zip.

[django013]

Hi,

Yes, XDG_DATA_HOME or XDG_CACHE_HOME, if not set, they are used by the system in away as if they would been set to the default, as already mentioned.

Well, I tried that, and it did not work.

I removed the font-files from ~/.fonts and changed the script to create and use ~/.local/share/fonts - but the system did not show up the fonts.
So I went back to use ~/.fonts which worked right out of the box.

May be, you (MX-developers) can extend fontconfig to scan ~/.conky as a font directory
So I consider my work as final for now and update the first post