Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: 1:1 migration from LauncherSettings >>> Settings #667

Merged
merged 8 commits into from
Dec 19, 2021

Conversation

skaldarnar
Copy link
Member

@skaldarnar skaldarnar commented Sep 1, 2021

Contains

This does not (yet) make use of any feature we gain by having JavaFX properties or bindings, but on the upside this should be a feature-equivalent migration to the new settings POJO.

I know that the migration is not pretty, but I'd like to improve on the details in separate follow-up PRs to keep the review load bearable.

Most changes where done with IntelliJ's "Type Migration" and direct migration of getter/setter calls to access of the property value.

How to test

Ensure that all tests are still passing when running gradlew test.

Start the launcher and play around with the settings.

  • changed settings should have an effect, e.g., whether to show pre-releases (NOTE: changing the locale only has an effect after restart. This is a known issues).
  • saved settings should be persisted and stay the same between restarts
  • no unexpected errors or crashes
  • both settings files (Java properties and JSON) are written to the launcher user directory (defaults to ~/.terasologylauncher/)

Based on #666

Contributes to #522

This prepares `Settings` to take over the role of `LauncherSettings` as
source of truth for the launcher settings.

The information is stored in JavaFX properties wrapping the actual
value. The use of properties allows for reactive bindings to simplify
automatic updates of the UI.

When storig a (legacy) `LauncherSettings` object we also deserialize an
equivalent `Settings` object to JSON. Vice versa, we can also read
`Settings` from a JSON file.

The new `Settings` object is not yet used.
…ad of file

Since it is the decision of `Settings` what file types to write, the file path should not be passed in from the outside. Instead, just the folder path can be controlled.

As a consequence, the exact file name(s) are an implementation detail and no longer need to be exposed by `Settings`.
This does not (yet) make use of any feature we gain by having JavaFX properties or bindings, but on the upside this should be a feature-equivalent migration to the new settings POJO.

I know that the migration is not pretty, but I'd like to improve on the details in separate follow-up PRs to keep the review load bearable.
@skaldarnar skaldarnar added Topic: Configuration Related to configuration design, settings and storage Type: Enhancement New features or noticable improvements. labels Sep 1, 2021
@skaldarnar skaldarnar changed the base branch from master to feat/fx-property-based-settings September 1, 2021 18:41
@jdrueckert
Copy link
Member

Launcher improvements

Base automatically changed from feat/fx-property-based-settings to master November 12, 2021 19:14
Copy link
Member

@jdrueckert jdrueckert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally tests out fine except for a language change not being loaded correctly.
I see it saved in both of the settings files in my ./terasologylauncher dir, but on start-up the launcher is always using English.

Nitpick: Consider aligning the Settings variable names to settings instead of launcherSettings.

@skaldarnar
Copy link
Member Author

The locale setting indeed brakes with this PR. The reason is that we no longer init() the LauncherSettings, and therefore don't call the initLocale() method anymore. The crux here is that this initLocale() method actually mutates global state in Languages 😟 (I think it's the only setting that does this).

void initLocale() {
final String localeStr = properties.getProperty(PROPERTY_LOCALE);
if (localeStr != null) {
Languages.init(localeStr);
if (!Languages.getCurrentLocale().toString().equals(localeStr)) {
logger.warn(WARN_MSG_INVALID_VALUE, localeStr, PROPERTY_LOCALE);
}
}
properties.setProperty(PROPERTY_LOCALE, Languages.getCurrentLocale().toString());
}

I'm currently trying to figure out at which place I'll add the Languages.update(...) call. Probably right after we've loaded the settings in the init task... 🤔 This is still more of a workaround than a proper solution, though.

@skaldarnar
Copy link
Member Author

skaldarnar commented Dec 19, 2021

@jdrueckert The language issue should be fixed by 286c4d7. I'd appreciate another review 🙃

It would be great to add tests for behavior like this at some point, but I'm not sure whether the current architecture would be a good point to start (a task running on a separate thread updating global state)...

@jdrueckert
Copy link
Member

jdrueckert commented Dec 19, 2021

Changes look fine so I approved it, but there seems to be a test failure?

@skaldarnar
Copy link
Member Author

There's indeed a failing test in the CI run:

TestRunGameTask > testTerminatedProcess() FAILED
    java.lang.AssertionError at TestRunGameTask.java:185
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended

62 tests completed, 1 failed
QuantumRenderer: shutdown

FAILURE: Build failed with an exception.

However, tests are running locally for me 😕

gradlew test
Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details

> Configure project :
Inferred project: TerasologyLauncher, version: 4.6.0-dev.13.uncommitted+feat.switch.to.new.settings.object.286c4d7

> Task :compileJava
Note: /home/skaldarnar/Code/movingblocks/terasologylauncher/src/main/java/org/terasology/launcher/repositories/GithubRepositoryAdapter.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /home/skaldarnar/Code/movingblocks/terasologylauncher/src/main/java/org/terasology/launcher/util/Languages.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :test
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.spf4j.log.SLF4JBridgeHandler$3 (file:/home/skaldarnar/.gradle/caches/modules-2/files-2.1/org.spf4j/spf4j-slf4j-test/8.8.5/5b9cd6e3ac26428529cff69edbcb7a714cd84804/spf4j-slf4j-test-8.8.5.jar) to field java.util.logging.LogRecord.needToInferCaller
WARNING: Please consider reporting this to the maintainers of org.spf4j.log.SLF4JBridgeHandler$3
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

BUILD SUCCESSFUL in 19s
15 actionable tasks: 4 executed, 11 up-to-date

I'll re-run the job...

@skaldarnar skaldarnar merged commit f0757ad into master Dec 19, 2021
@skaldarnar skaldarnar deleted the feat/switch-to-new-settings-object branch December 19, 2021 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Topic: Configuration Related to configuration design, settings and storage Type: Enhancement New features or noticable improvements.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants