Unique settings per portable instance

[GoogleIsEvil]

I run many versions of Sumatra and many instances of each for various things. Some of this has to do with multiple monitors(to avoid having to constantly move the window to the monitor I'm using and others is because I use it in various automations(e.g., certain apps configured to use certain instances) or whatever it may be.

The self-contained portable version is nice but can the settings file be localized to be specific to that version so that multiple executables can be stored in the same directory without conflict?

This would be very simple such as having it use the same name as the exe then it is just a matter of making various names such as "SumatraPDF1.exe"[and corresponding settings become SumatraPDF1.settings.ini" or whatever], ..., "SumatraPDF8.exe", etc.

This way rather than having to have multiple directories I can just have a single one that houses all of the instances used. This also makes updating much nicer.

[GitHubRulesOK]

Ok there are two things to consider
The current version of pre-release "portable" does not hold settings in the same folder as EXE which other prior versions did. (Dont Ask!) but then you can have an old exe and a new exe without any problems (I often mix several at a time, but it can lead to issues.)

When you want to force a settings to be read from a FOLDER you can use the -appdata foldername command with the one exe as different uses but beware in memory conflict thus avoid one exe 2 different settings folders at same time !

This is a problem use where set 2 has been called but set1 is active in memory and thus when closing there could be instability

thus we can have EXE in a folder and subfolders with their own settings for carry to start-up at different sites

[GoogleIsEvil]

I typically run multiple instances at the same time. E.g., I have multiple monitors in different places for different tasks(e.g., one is for music, other for programming, etc). One is used to read sheet music. Many times both are open at the same time as to avoid having to reopen.

So I actually need it to work at the same time. This shouldn't stop me from using multiple exe's though? e.g., "sumatrapdf1.exe --appdata set1" "sumatrapdf2.exe --appdata set2" as there should be no memory conflicts?

Maybe --appdata can be extended to accept a file? "sumatrapdf1.exe --appdata set1.ini" and reads it from current director if is missing.

Then maybe better localization could be done for multiple instances to avoid the memory conflict? This would avoid the need for multiplying the exe's.

Possibly a very simple solution to this might be:

"sumatrapdf.exe --newInstance --appdata set1"

and what newInstance does is simply copy the executable to a temp dir with a unique filename and execute it(basically automating and hiding what I do manually and avoiding keeping multiple executables around). The only issue here is that the process would need to be invoked independently rather than as a sub process to avoid them being terminated when the main process is. E.g., if sumatrapdf.exe is run without --newInstance or it is terminated we do not want all the other processes terminated.

[GitHubRulesOK]

-appdata folder is a long time (legacy) mechanism for holding multiple file types such as thumbnails sub folder, secondary dll, crashreports etc etc so is an application data folder with the ini.txt file as simply just one ini[tial] component.

It was never really well documented and only used for keeping 2 sets of roaming data apart from each other.

If you have 2 exe requirements it is simplest to just keep them in their own folders like 2 different users do in system private appdata.

For 2 users to use one exe it needs to be installed.