Migrate EGSnrc configuration files to ~/.config/EGSnrc/

[ftessier]

Problem Description

The current method of modifying the .bashrc file to configure EGSnrc is outdated and cumbersome. Modern software typically stores configuration in ~/.config/ directories, reducing clutter in the home directory.

Issues with the current .bashrc approach:

• Confuses new Linux users by requiring manual edits.
• Configuration script doesn't support all shells.
• Added lines are installation-dependent.
• EGSnrc works in the current shell if commands are pasted, but then not in a new terminal.
• Environment variables need manual clearing when installing separate EGSnrc instances.

Proposed Solution

Adopt the XDG Base Directory Specification from freedesktop.org:

$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If not set, it defaults to $HOME/.config.

The key shell variables ($EGS_HOME, $EGS_CONFIG, etc.) should be moved to:

$XDG_CONFIG_HOME/EGSnrc/ (defaulting to $HOME/.config/EGSnrc/).

This directory would contain an appropriate shell config file (e.g., EGSnrc.bash, EGSnrc.fish). This setup keeps EGSnrc configurations isolated and easy to transfer between installations. Ideally, all local EGSnrc configurations, including specs/*.conf, would be stored here, making setup more user-friendly.

This approach means no .bashrc modifications, with a clear error message if configurations are missing (e.g., No EGSnrc configuration found in /home/user/.config/EGSnrc/).

Alternatives Considered

Appending directly to .bashrc from the configuration script. This is non-transparent and could confuse users further.

Steps to Implement

• Identify all dependencies on $EGS_HOME, $EGS_CONFIG, $HEN_HOUSE, etc.
• Define the structure for ~/.config/EGSnrc to support multiple configurations.
• Update configuration scripts to use the new location.
• Add an option to the configuration script for custom config paths.
• Update scripts and Makefiles to use the new location.
• Modify applications to use the new configuration directory.

Any feedback or suggestions are welcome, especially regarding making the transition smooth for users. What do you think?

[crcrewso]

What would the user migration look like?
Would Windows installations also be migrated to %localappdata%?
Or is it time to switch to a WSL only support model for Windows?
I'm off next week so I could work on this.

Edit:
Do you want a new branch that is focused on tagging these dependencies? What tagging format/toooling should be used?

[ftessier]

If there are enough people (and I don't know what that number is!) who confirm as you have @crcrewso that WSL works as expected for Windows installation, I would be in favour of moving in that direction, yes.

Your help is welcome anytime! Feel free to create a branch and a draft pull request (linking to this issue) and we carry on conversation there!

The first step is to clarify the scope of this change, for which I don't even have a clear picture yet! Is it a relatively small change, or is it extensive throughout the code base?

[mchamberland]

Two things:

1. Installing on Windows via WSL was super smooth and one of the most pleasant installation experiences I've had with EGSnrc.

2. There might be some EGSnrc users for whom WSL is not available. For example, I know of of some egs_brachy users who are stuck having to do the non-WSL Windows installation because their local IT does not allow WSL. But surely there can't be that many of those users around...?

[ftessier]

Good point @mchamberland. That is indeed the case for our Windows machines managed by NRC. I would not remove the Windows installer, but recommend WSL as the favoured method if availabe.

Can I quote you on the first point for marketing purposes? 😆