so for the language display issue, i suspect it happened when i renamed Preferences class to AppPreferences
the comment: # Preferences (Frame) in all PDE.properties automatically changed to # AppPreferences (Frame) leading to corruption of some files (idk why tho)

it's fixed now

Hi @AhmedMagedC Thank you for the PR! Sorry I got a little busy, hope to get to this soon!

Hi @AhmedMagedC Sorry it took me so long to take a look at your PR again! and again thank you for your efforts, it's helping me a lot trying figure out how to refactor some of these intertwined elements.

Looking at your PR and #1164 I think it is important moving forward that we only migrate one class at a time. I would suggest that any functionality in the Preferences class that is currently causing you to have to migrate the Messages and Base classes for example, should be taken out of the Preferences class. That will make the code a little bit more flexible in the future.

Hi @AhmedMagedC Sorry it took me so long to take a look at your PR again! and again thank you for your efforts, it's helping me a lot trying figure out how to refactor some of these intertwined elements.

Looking at your PR and #1164 I think it is important moving forward that we only migrate one class at a time. I would suggest that any functionality in the Preferences class that is currently causing you to have to migrate the Messages and Base classes for example, should be taken out of the Preferences class. That will make the code a little bit more flexible in the future.

Hi @Stefterv , It's okay it's also the first time for me trying to refactor a codebase by decoupling tightly-coupled classes

im not sure i follow you,
if i were to move Messages back to app module, how might we decouple Preferences from using it?

also for the change of getting the setting folder for each OS is now independent of Base class, i dont think i should undo this change it will make Preferences impossible to be a standalone class

Yes exactly, instead of migrating Messages along with Preferences, app.utils.Preferences should throw an error that is caught within the encapsulating app.Preferences, same with the paths app.utils.Preferences could take a path as an argument on creation and that argument is set in app.Preferences

Hi @Stefterv , Sorry for the late reply i was busy for the last couple of weeks

i see now that we should currently focus on migrating Preference class
i migrated Messages with it in the first place to be able to print the error messages
but as you suggested i can simply throw them then caught and handled in app.preferece class

for the paths, i dont undetstand why i should undo it
now i fully docoupled getting the preference file location from the app module
you can simply call SettingsResolver.getSettingsFolder(); which will get you the location without the need to depend on app module

Hi @AhmedMagedC! Again your work on this has been invaluable in figuring out a strategy for starting to untangle some of these parts.

I’m recommending we tackle one class at a time to avoid regressions and the risk of having to undo a PR because of an unforeseen side effect in the existing code.

For me, an important part of these decoupling steps is making the coupling between classes more visible. That way, we can gradually refine each class to have clearer inputs and outputs.