Settings & Storage overview

Preference readiness and delayed restoration

A settings file can exist before the client has exposed the live preference object. UI readiness and preference readiness are separate: a window may already be rendered while Settings.g_instance.userPrefs is still unavailable.

  • Treat an unavailable preference section as “not ready,” not as an empty configuration.
  • Use a bounded retry owned by the current account or window generation.
  • Mark restoration complete only after the preference section was read successfully.
  • If the read succeeds after the UI appeared, immediately apply the restored value to the current UI.
  • Cancel or invalidate the retry when the account, view, or owning context changes.

Illustrative Python 2.7 example; retry ownership is delegated. The missing retry_later helper receives the same attempt and its result is returned directly. This body does not increment attempts, schedule or cancel callbacks, or reject an old account/window generation. It returns False at the supplied limit; boundedness and teardown require the helper's own verified contract.

def restore_position(attempt=0):
    settings = getattr(Settings, 'g_instance', None)
    prefs = getattr(settings, 'userPrefs', None) if settings else None
    if prefs is None:
        return retry_later(attempt) if attempt < MAX_ATTEMPTS else False

    screen_w, screen_h = GUI.screenResolution()
    section = prefs['exampleOverlay']
    x = section.readInt('x', int(screen_w // 2))
    y = section.readInt('y', int(screen_h // 2))
    apply_position(x, y)
    return True

A false-like settings object skips its preference lookup; only prefs is None selects the unavailable branch. Other values continue to indexing. Screen defaults are converted before each read, and returned coordinates go directly to the unspecified apply_position. Its return is ignored: True means only that these calls returned normally. There is no explicit section-creation call, coordinate validation, scaling, clamping, completed-state flag, save or UI acceptance receipt. Lookup, screen, read and application failures propagate.

Verify the concrete readiness accessor

The concrete SettingsCore.isReady can differ from its interface declaration. In the implementation described here, core.isReady() reads readiness; bool(core.isReady) only tests the bound method. Check the resolved implementation rather than assuming a decorator or adding a universal property/method fallback.

Normal service configuration initializes the core. Its readiness flag still does not establish cache synchronization or completed server-option application; check those stages separately.