Using a CLAMTK_HOME variable.

[denisfa]

Hey!

What do you think about using an env variable CLAMTK_HOME to set where the clamTK configuration files should be saved? At this time, it is hardcoded to /home/USER/.clamtk. I have seen other software giving users the option to set where files should be saved using env variables (mednaffen with MEDNAFEN_HOME, for example [1]). The main advantage of removing hidden files from HOME is to allow users to have more control of what should be saved and where.

This is a proof-of-concept patch to show how we just need a few lines to get this going. clamtk_home.txt

I did this for my fork and everything worked fine! I can create a pull request if you like this idea!

Thanks for your attention! I’m looking forward to your reply!

EDIT: To be more precise, if CLAMTK_HOME is set, then we use it; otherwise, fallbacks to /home/USER/.clamtk.

[1] https://mednafen.github.io/documentation/#Section_base_directory

[dave-theunsub]

Hi @denisfa , That sounds like a pretty easy and doable idea. I'll add it to the list of things for the next version.

Thanks, Dave M

[denisfa]

Hey, long time no see. I would like to further explain this change.

The objective is to adopt the XDG Base Directory Specification. This is a way to manage how files should be organized. It fits a great part of the issue described in my previous comment. This can be done by using an environment variable, like suggested, but using the XDG Base Directory Specification is considered a more standard way to solve this (many software support it like Git, GIMP, chromium, python-pip, pulseaudio, systemd).

That being said, what do you think about it? There are libs in perl ready like this one. I did some testing in my fork and it does not need many changes (only App.pm file).

If you are interested, you will need to define the location of each folder/file within the XDG spec. There are three important variables:

Variable	Default value	Idea
XDG_CACHE_HOME	$HOME/.cache	user specific non-essential data files should be stored
XDG_CONFIG_HOME	$HOME/.config	user specific configuration files should be stored
XDG_DATA_HOME	$HOME/.local/share	user specific data files should be stored

As a sidenote, your "trash" folder already uses the XDG spec for "Trash" directory ($XDG_DATA_HOME/Trash). If this does not exist (and Desktop Environment does not create the folder), then "$HOME/.Trash" is used.

These are the files/folders affected by it. I did as presented in my fork, but you should check if everything is in the right location according to the meaning of each one regarding the XDG spec and where you imagine it should be.

File/Folder	XDG Location
trash_dir	$XDG_DATA_HOME/Trash
viruses	$XDG_DATA_HOME/clamtk/viruses
history	$XDG_DATA_HOME/clamtk/history
prefs	$XDG_CONFIG_HOME/clamtk/prefs
restore	$XDG_DATA_HOME/clamtk/restore
db	$XDG_DATA_HOME/clamtk/db

Thanks for your attention!

[dave-theunsub]

@denisfa - I like that. The home directory can get pretty cluttered with "dot" directories.

The thing to figure out next is moving to that specification. It's not too hard code-wise, but a few questions - just move it without letting the user know? Or let them know? Or give them a choice? What if it fails for some reason? Use nag windows to keep pestering the user :) ?

Otherwise good idea! Thank you.

respectfully, Dave M

[denisfa]

Hey,

just move it without letting the user know? Or let them know?

The user should know about this, but it can be as simple as a note in changelog or news (version 5.XX supports XDG spec - we use these directories: "list dirs").

Or give them a choice?

This can be tricky. "If it ain't broken, don't fix it"; allowing users to have a choice increases maintenance cost. If it follows the XDG spec, it is better to have a shell script or something to move the older configuration to the new one and that's all. Only use the new configuration. Again using docs/wiki/news to let the user know. This is actually simple because it has always been hardcoded to "$HOME/.clamtk".

What if it fails for some reason? Use nag windows to keep pestering the user :) ?

The files will be the same, but just under different locations. You will not ask the user "where are the configs and data?". Either they are there or they need to be created. It does not change the current behaviour of creating files with default values when they don't exist. Unless you mean something else?

Thanks for your attention!