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

Preferences written on helper creation #342

Closed
mdickinson opened this issue Jun 27, 2024 · 0 comments · Fixed by #343
Closed

Preferences written on helper creation #342

mdickinson opened this issue Jun 27, 2024 · 0 comments · Fixed by #343

Comments

@mdickinson
Copy link
Member

mdickinson commented Jun 27, 2024

Preferences are currently written the first time a PreferencesHelper for those preferences is created. This leads to some surprising behaviour, especially in scoped preferences. Here's an example test case that currently fails:

    def test_preferences_not_written_on_helper_creation(self):

        class AppPreferencesHelper(PreferencesHelper):
            #: The node that contains the preferences.
            preferences_path = "app"

            #: The user's favourite colour
            color = Str()

        default_preferences = Preferences(name="default")
        default_preferences.set("app.color", "red")

        application_preferences = Preferences(name="application")
        preferences = ScopedPreferences(
            scopes=[application_preferences, default_preferences]
        )
        self.assertIsNone(application_preferences.get("app.color"))

        # Then creation of the helper should not cause the application
        # preferences to change.
        AppPreferencesHelper(preferences=preferences)
        self.assertIsNone(application_preferences.get("app.color"))

This test case fails at the second self.assertIsNotNone line: the preferences from the default scope have been written into the application scope.

mdickinson added a commit that referenced this issue Jul 4, 2024
This PR fixes the `PreferencesHelper` to avoid writing to the
preferences the first time a helper is created for a given `Preferences`
object.

The issue was that on creation, `PreferencesHelper._initialize` was
being called twice: once with `notify=False` and again with
`notify=True`, as a result of the listener to the `preferences` trait.
This PR avoids the second call by making that listener only run post
creation (using `post_init=True`).

Closes #342
Closes #74
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant