Re: [Bug-gnubg] How to change the directory where settings saved?

[Michael Petch]

On 2013-10-27 14:21, Philippe Michel wrote:
> The portable version would then be started from a short script that
> determines where it is run from, sets the environment variable
> accordingly and launches the real executable with -s
> %GNUBGDATA\preferences or something similar.

The idea of some form of environment variable isn't a bad one. It seems
like it may be a reasonable idea.

And as I posted earlier today, relative paths are accepted on Windows. I
used . (period) as an example or even ..\somedir . Your issue regarding
the paths written to the config the first time things are run can be a
bit of a problem, and your idea could overcome this.

In my previous experimentation with the -s parameter on Windows I
realized that shortcuts to GNUBG (that are on the USB drive) have an
interesting limitation. Windows shortcuts do not allow you to specify a
relative path to the executable. So when you create a shortcut that is
in the same directory as GNUBG on the USB stick it requires you to put
in a full path including drive letter into any shotcut you create
9Tryign to add a relative location for an executable is blocked by a
windows error). As you point out that drive letter could change.

The only way to pass a command line parameter to GNUBG and have it work
with relative paths is to create a batch (.cmd or .bat) file that
launches GNUBG.

For the MS Windows world, I was toying with a solution a long the lines
of your suggestion since portability seems to be a feature request
there. The idea is to add an option to the installer for those who wish
to create a portable install (Some installers have a similar advanced
portable install feature). This advanced/expert option would be a page that:

a) Asks users if they wish to install to a portable device (ie. USB)
b) Ask user for a relative path to install preferences. Default is blank
which would translate to a period (.) directory being passed to GNUBG
which would result in the base preferences directory being that of the
install directory.
c) Installer launches gnubg-cli.exe, issues "save settings" command,
then exits. This creates a new configuration file (gnubgautorc) but with
absolute paths.
d) Once gnubg-cli exits the installer reads the config file and does a
simple text deletion. All the absolute paths (The install directory
base) is simply removed.
d) Create a batch file (.cmd) in the install directory that launches
GNUBG with the required -s parameter.

Once installed a portable user launches the batch file to start GNUBG.

This doesn't require changes to GNUBG, but does require the installer to
do text substitution on an initially created gnubgautorc resulting in
making the data path elements relative (sound files, MET file etc).

An environment variable as you suggests isn't a bad idea, but puts the
logic in GNUBG. Both ways do handle the portability issue. I don't think
portability really applies to *nix given how we do installations, and
the required components (shared libraries) are installed separately by
the package manager of the platform. On MS Windows the way we do
installs we make available all the DLLs and required files inside the
GNUBG install directory to help mitigate (but not eliminate) DLL hell,
which lends itself to creating portable variations. I don't really think
the issue of portability is one that I would extend to non-MS Windows
platforms.

-- 
Michael Petch
GNU Backgammon Maintainer / Developer
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304