Portable Mode (Windows)

[smaragdus]

As of version 1.7.0 PDF Arranger is not exactly portable as it saves its configuration file (config.ini) in AppData:

C:\Users\User\AppData\Roaming\pdfarranger\config.ini

My request- when PDF Arranger starts it should check whether its program folder contains the configuration file (config.ini) and if it is there it should use it (load data from and save data to this configuration file, not using AppData for the configuration file, but the program folder instead).

This small change would make PDF Arranger truly portable (not writing outside its own folder) and I suppose that this feature will not be hard to be implemented.

[dreua]

The program folder would be which exactly? The folder containing pdfarranger.py?

[smaragdus]

@dreua

I should have been more clear and specific I guess- by program folder I mean the one which contains the executable- pdfarranger.exe, the dlls and the two subfolders- lib and share. In short- when PDF Arranger starts it checks this folder (the one containing the executable- pdfarranger.exe) for the configuration file- config.ini, and if it is to be found there it is used. Even shorter- if config.ini is present in program folder it triggers portable mode- the configuration file is not saved in AppData but in program folder only.

Regards

[jeromerobert]

It sounds good, but let's wrap it in an if os.name == 'nt': because it doesn't have much interest elsewhere than on Windows.

[smaragdus]

@jeromerobert

Yes, I forgot to say that I meant portable mode on Windows OS.

[GitHubRulesOK]

It sounds good, but let's wrap it in an if os.name == 'nt': because it doesn't have much interest elsewhere than on Windows.

Consider Parallels/Wine/WLS users in dual mode and I have no clue what os.name reactos uses ?

Its common to include portable.dat or other flaglet in an executable directory to signal data files are stored locally e.g. not relative to "home" or "usr" having config.ini local seems to be adequate enough signal.

[dreua]

@jeromerobert I think @GitHubRulesOK has a point here. Why do you think limiting this function to os.name == 'nt' would be necessary? Maybe it's really fine to just check for this file in any case.

[jeromerobert]

os.name is not related to the host operating system but to the python interpreter. So far the only Windows distribution of PDF Arranger is the one I build and it has os.name == 'nt' wherever it runs.

As far as I know the only Windows Python interpreter which may have os.name != 'nt' is Cygwin/MSYS and it is already portable because it provides ways to store configuration file wherever you wants. Anyway I don't expect anyone bored enough to run PDF Arranger in Cygwin/MSYS.

Storing configuration within the application folder will be considered as dirty everywhere else than on Windows.

[dreua]

Storing configuration within the application folder will be concidered as dirty everywhere else than on Windows.

I agree. However, we are not actively writing to this directory, just checking if a file exists there and using it in case it does. I don't see how that would be a problem on any OS but maybe I'm missing something?

[jeromerobert]

However, we are not actively writing to this directory

I think we do. Quoting smaragdus: if config.ini is present in program folder it triggers portable mode- the configuration file is not saved in AppData but in program folder only. I think he is right, that's what portable mode users will expect.

[dreua]

Correction to my statement: We are not actively creating ini files in the application directory. If someone else deliberately did so, we are writing to it, that is true. I'd consider this an acceptable edge case, but if you are more comfortable limiting this to os.name == 'nt' that is fine with me, let's do this!

[dreua]

I just created a new label and this issue is the first to test it: I think this issue is a good starter, well defined and a reasonable addition to PDF Arranger. Unfortunately I'm not interested in implementing it myself because I would not benefit from it and my time is limited. I would, however, give guidance to new contributors interested in implementing and testing this. (The automated exe builds will make the latter quite simple, even for beginners, thanks Jerome!)

(This does not mean that "old" contributors should avoid implementing and closing this, of course.)

[midaspt]

Excuse for being late to this discussion, but as a long time user of portable Windows software, it's my opinion that PDFArranger cannot call itself portable on Windows if it writes settings to '%APPDATA%'.

The current version available is misleadingly labelled "Portable" when it's simply a no-installer package.

Case in point, should a user extract that version to a USB drive, run the program on computer A, then close it and move it to computer B, all previous settings will be unavailable, as they would have been left behind -- which makes it pointless to even write them in such case.

If there's a problem with writing anything to the program folder, a viable alternative would be to write settings to a custom (sub?)folder (e.g., data, conf or portable), whose presence would then trigger the proper portable mode.

[GitHubRulesOK]

@midaspt
the norm in such cases is either edit the source to suit different usage or much simpler mod startup shortcut to something like

C:\Windows\System32\cmd.exe /c "set Appdata=C:\MyApps\pdfarranger\AppData&start C:\MyApps\pdfarranger\pdfarranger.exe"

or more portable but drive root still needs to be defined so still not perfect.

%comspec% /d /v /c "set AppData=C:\MyApps\pdfarranger\AppData&start !AppData!\..\pdfarranger.exe"

You need to add the AppData folder in pdfarranger folder so for above example its found as C:\MyApps\pdfarranger\AppData and using minimised cmd in shortcut avoids the annoying "in your face" black screen.

other portable roaming app use switches like SumatraPDF.exe -appdata "x:\usb stick\app\app name" however thats not needed in that pdf app because it holds config next to exe

@smaragdus I cant login to Portable Freeware those silly captcha questions are too obtuse. perhaps you could add above suggestion

[midaspt]

@GitHubRulesOK: The issue here is PDFArranger is distributed with a pre-compiled executable, as is normal with Windows programs -- not in a py file that is invoked as a parameter passed to the Python executable -- so those solutions don't really apply.

Moreover, most Windows users are not at all accustomed to such a way of running programs; one usually just runs whatever executable the program is contained in.

Mind you, it would be no big trouble to pass CLI parameters to an executable to make it truly portable, which could be easily done with a batch file, for instance -- one of the many options that are part of a toolset used to make applications portable.

In case this interests anyone, take a look at PortableFreeware.com forums...

[kbengs]

@smaragdus @midaspt The build found here should work as suggested:
https://github.com/pdfarranger/pdfarranger/actions/runs/1472128899

[GitHubRulesOK]

@kbengs
Nice
is that a separate version or will be official PR in 1.9 ?
can this issue be closed and i delete workaround

[kbengs]

The issue should close automatically if/when the PR gets merged, so just leave it open.
The fix should be included in 1.8.1 which I think will be release not too far in the future.

[midaspt]

The build found here should work as suggested: https://github.com/pdfarranger/pdfarranger/actions/runs/1472128899.

Can confirm, tried it without getting any visible unwanted artifacts in '%APPDATA%' -- settings were written to 'config.ini' in program folder as expected.

[jeromerobert]

@kbengs thank you. Just 2 remarks/questions about your PR (I write here rather than in the PR because it should be of interest to all those who participate in this issue.).

• os.path.isfile('./config.ini') means that we look for config.ini the folder from which pdfarranger.exe was run. This is not always the folder which contains pdfarranger.exe. It means that depending on the way the user run pdfarranger.exe, the "portable mode" will be enabled or not. Is that expected ?

• On my pro laptop I always install PDF Arranger portable because I don't have right to install the msi. Yet I want to keep config.ini in %APPDATA%. I think I'm not the only one in that cas (this is the "no-installer" usage midaspt write about). With your PR I'll be able to do that by manually removing the empty config.ini after each new installation of pdfarranger. Am I right ?

As this is behavior change I think it should be in 1.9.0 and not 1.8.1, so I would prefer to keep that PR on hold until 1.8.1 is released.

[jeromerobert]

To clarify... I think we need both "no-install" and "portable" mode. The default behavior of the zip will be either "no-install", either "portable" (I guess we can't have both). With your PR we'll have the "portable" mode by default. To switch to the "no-install" mode the user will just have to delete the config.ini file.

It's fine with me (as a user), but I wonder if this is a common behavior among Windows applications.

[GitHubRulesOK]

In portable circles and I have been using them since the 1960's when they were in ones back pocket, then onto floppies in ones shirt pocket, the aim is to leave no footprint on the device (even if windows prefetch and reg mui is recording their usage)
To be portable the data travels on a stick with the application. There is no such thing as stealth in this centuries Windows.

[kbengs]

Remark 1: Good point, I think that would be unexpected. I think we should always check if config.ini is found in same folder as pdfarranger.exe. I'll try to modify it that way.

Remark 2: We could mention in README.md that it is possible to store config.ini in %APPDATA% by simply removing config.ini in the zip file. What do you think about that?

[midaspt]

Remark 2: We could mention in README.md that it is possible to store config.ini in %APPDATA% by simply removing config.ini in the zip file. What do you think about that?

FYI, this is the normal behavior of most Windows portable apps.

[GitHubRulesOK]

Hmmm I was pleased to download win32.zip artifact however on run it says it wont work on my win32 suggesting I need to install Windows 64 on this 32 bit machine ! Did I miss a note on limitations since I could not see one? If its only win 64 then I suggest the file be called win64

[dreua]

C'mon 32bit windows is an extreme edge case by now, just reinstall in 64 bits and move on

[GitHubRulesOK]

@dreua I can install in millliseconds on 64bits in sandbox no need for portable
I only need portable for older 32 machines that dont have a sandbox

[jeromerobert]

I will not work on a 32-bit Windows version, but contributions are welcome.

[GitHubRulesOK]

I respectfully suggest the build be tagged Win64 to reduce user expectations, but thanks for the build that those without a fast 64bit sandbox can use on a USB stick

[jeromerobert]

https://stackoverflow.com/questions/61776207/where-does-win32-come-from-when-im-using-windows-64bit