Custom preferences.txt location not working in Processing 4.5.2

[glvjr]

Most appropriate sub-area of Processing 4?

PDE

Processing version

Processing 4.5.2 portable version (processing-4.5.2-windows-x64-portable.zip)

Operating system

Windows 10

Bug description

When a custom location for preferences.txt is defined in settings.txt:

1. Processing creates a preferences.txt in that directory but does not write to (update) that file.
2. Preference changes are written to the default preferences directory instead and are not used.
3. Processing will use the custom preferences.txt if it is manually edited.

Processing should write to (update) the configured custom preferences.txt location.

This works as expected in Processing 4.4.x

Steps to reproduce this

This is a custom environment on my system.

Steps to reproduce:

1. Unzip processing-4.5.2-windows-x64-portable.zip into:
   D:\Program_Portable\
   This creates: D:\Program_Portable\Processing\
2. Create this folder (must be created manually):
   D:\Program_Portable\Processing\mypreferences\
3. Create this file:
   D:\Program_Portable\Processing\app\resources\lib\settings.txt
4. Put this single line into settings.txt:
   settings.path=D:\Program_Portable\Processing\mypreferences
5. Launch Processing.
6. Confirm it creates:
   D:\Program_Portable\Processing\mypreferences\preferences.txt
7. Change any preference in the UI (example: Editor font size and Console font size).
8. Close Processing.
9. Check which file actually changed:
   • D:\Program_Portable\Processing\mypreferences\preferences.txt
   • %APPDATA%\Processing\preferences.txt

Actual result:

• Processing creates D:\Program_Portable\Processing\mypreferences\preferences.txt
• Processing does not write preference changes to it.
• Preference changes are written to %APPDATA%\Processing\preferences.txt instead.

Expected result:

• Processing should read/write preferences using the folder specified by settings.path.
• You should see the Editor font size change in real time when modifying it with the scrollbar

Reference:

1. https://discourse.processing.org/t/custom-location-for-preferences-txt-not-working-with-processing-4-5-2/47872
2. https://github.com/processing/processing4/wiki/Preferences#sketchbook-and-settings-location
3. https://github.com/processing/processing4/releases

Additional context

See Processing Discourse for additional context:

https://discourse.processing.org/t/custom-location-for-preferences-txt-not-working-with-processing-4-5-2/47872

Would you like to work on the issue?

No, I’m just reporting the issue

[avinxshKD]

I'd like to work on this, pls assign

[SableRaf]

@avinxshKD Hey, thanks for wanting to help out again

Just a heads-up: as we discussed on #1433, commenting "please assign" without a proposed approach or investigation into the issue goes against our contribution guidelines which ask that you include a brief explanation of how you'd tackle the problem before requesting assignment.

I totally understand college keeps you busy. Just know that consistently skipping the process creates extra work for maintainers and isn't fair to other contributors either. Quality over quantity 😉

If you're interested in this issue, a great next step would be try reproducing the issue, dig into the codebase for the cause of the bug, and share your findings and proposed fix here. That kind of contribution is always welcome!

[avinxshKD]

Hey @SableRaf, you're absolutely right and I apologize. I got caught up in the excitement of wanting to contribute and skipped the actual work. And yeah college has been hectic but that's no excuse for skipping the process. That's on me, so sorry

i looked into it and yeah it's broken. the new kotlin preferences code (Preferences.kt line 84) just calls Settings.getFolder() directly instead of checking if theres a settings override first. the old java version used to check Base.getSettingsOverride() before grabbing the default folder. so settings.txt gets read on startup but then preferences get saved to appdata anyway

fix should be pretty simple - justn check the override first:

val settingsFolder = Base.getSettingsOverride() ?: Settings.getFolder()

can test it with the steps from the issue report if you want me to make a pr. will do the homework first next time, thanks