Repository navigation
Making Preferences standalone #1104
Description
Activity
@AhmedMagedC is this something you would be interested in working on?
@Stefterv Thanks for suggesting me to implement this, and yes i'm interested into working on it
unfortunately though im currently busy with college having practical exams this week, i can start working on it once i finish
Reacted by Stef TerveldeHi @Stefterv , I would like to show my approach to make sure I'm moving in the right direction.
I will move
Preferencesclass into:app:utilmodule insideprocessing.utilspackage, while keepingAppPreferencesclass inside:appmodule which will extendPreferencesmain functionalities likeload(),get(),set()and then provide functionalities that depend on:applikesetFont(),getFont()but for the
Prefernecesclass, getting thepreferences.txtfile is platform-dependent so i thought of creatingprocessing.utils.platformpackage to overridegetSettingFolder()for each platform (which is already implemented inprocessing.app.platformpackage i will just copy it)and for things like getting the
default.txtfile or ,setting.txt(for portable versions), I can use built-in JAR Resources System instead of the deprecatedPlatform.getContentFile()which will make it independent ofapp.Baseandapp.Platformclassesso what do you think?
Hi @AhmedMagedC, Thank you for writing down the approach.
I will move Preferences class into :app:util module inside processing.utils package, while keeping AppPreferences class inside :app module which will extend Preferences main functionalities like load(), get(), set() and then provide functionalities that depend on :app like setFont(), getFont()
and for things like getting the default.txt file or ,setting.txt (for portable versions), I can use built-in JAR Resources System instead of the deprecated Platform.getContentFile() which will make it independent of app.Base and app.Platform classes
Perfect 👍
but for the Preferneces class, getting the preferences.txt file is platform-dependent so i thought of creating processing.utils.platform package to override getSettingFolder() for each platform (which is already implemented in processing.app.platform package i will just copy it)
Let's use the existing
Platformfor now, I'd rather avoid duplicating code where we can. Then we create a new issue for thePlatformclass similar to this one after creating the newPreferencesis finished.Thank you for catching the dependency on
Platformearly on!Reacted by AhmedMagedReacted by Raphaël de CourvilleHi @Stefterv , so i managed to migrate the preference class to utils module and it properly compiles and runs
i took a different approach than using the Platform class because that made cyclic dependency problem (utils depend on app, app depends on utils)
i wanna make a PR so you and other devs can review the work done and prompts changes if needed
also note that i didnt yet work on the rest of requirements, i will once the migration alone makes sense
Hi @AhmedMagedC, thanks so much for the update and the work you’ve done so far! Please go ahead and open a draft PR. We can take a look and continue the discussion there.
Hi @AhmedMagedC Thank you so much for this initial work and thank you for checking in to see if this approach is correct. I learned the following:
By renaming the class to
AppPreferenceswe have to update all the references as well which makes the PR hard to check. I would suggest that we instead create a new classPreferencesinutilsand extend the existing class from there. That way we can slowly migrate over functionality whilst keeping the references the same. Also some functionality could be extended more easily by overriding methods in theappversion of the class.Looking at the
utils.PreferencesI would like the system proxy stuff to be in theapp.Preferencesinstead. I would suggest that keeping all side-effects out of the utils classI'm happy for the
Locationclasses that you have now to be a single class/file.In any case, this has been super helpful and I hope you are also still excited to implement these changes! Again sorry that I assigned this to you and then did not have the time to review your work sooner.
Hi @Stefterv , Thanks for the suggestions and I'm still interested in implementing these changes and finishing the todo tasks
for the first point, I have already made the
Preferencesclass inutilswhich is extended byAppPreferences, i will just renameAppPreferencesBack to It's original namePreferenceswhich would resolve these many changes of references.for the second point, I don't fully understand what do you mean by
side-effectscan you please elaborate more?Reacted by Stef TerveldeSure! Side effects are in this case configuration changes that are not explicitely requested. The
Preferencesclass seems like it should only handle saving and loading preferences, but here it also changes the proxy settings while the program is running. I think a utility class should focus on just one thing.Reacted by AhmedMaged@Stefterv , I made the changes I hope that's what you had in mind
i renamed the
AppPreferencesandAppMessagesback to the original namePreferencesandMessagesrespectivelyand i moved extra configurations to
app.preferenceswhich is unrelated to theutils.preferencesclass like- explicitly set bgcolor
- set sketchbook path
- proxies configuration
- added 2 commits that reference this issue
on Aug 4, 2026
For the migration of the internal Gradle runner, I'm running into trouble with the
Preferencesclass.Problem description
Currently
Preferencesis tightly coupled with the PDE through the use of theBase,Messages,ToolkitandLanguageclasses. These classes do not operate outside of the PDE, thus not allowing reuse of thePreferencesclass in other modules within Processing (e.g. Gradle plugins, Processing CLI, Processing pre-processor, etc.)Proposed solution
Migrate the
Preferencesclass to a standalone version.:appby moving it to a:app:utilsmodule.:appinto aAppPreferencesclass or into other relevant areas of the PDEPreferences, a few of the top of my head would be:\workcoreSteps taken so far
utilsin theappfolder with the following settings (see image below)processing.utilsto the newly created modulePrefrencesclass andRefactor -> Move Class...and moving it to the newly createdprocessing.utilspackage