Skip to content

Initial migratable Settings#1126

Open
timbms wants to merge 2 commits into
openhab:developfrom
DigiH:settings
Open

Initial migratable Settings#1126
timbms wants to merge 2 commits into
openhab:developfrom
DigiH:settings

Conversation

@timbms

@timbms timbms commented Mar 31, 2026

Copy link
Copy Markdown
Contributor

No description provided.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR refactors the “show search field” setting to be stored as part of per-home preferences and makes HomePreferences decoding more resilient to schema changes, supporting smoother preference migrations.

Changes:

  • Added showSearchField to HomePreferences and implemented a custom init(from:) to supply defaults for missing keys during decoding.
  • Removed ApplicationPreferences and updated UI/view-model code to read/write showSearchField via currentHomePreferences.
  • Updated migration logic to carry forward the legacy showSearchField value into the active home.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File Description
OpenHABCore/Sources/OpenHABCore/Util/Preferences.swift Adds migratable decoding for HomePreferences, moves showSearchField into home-scoped preferences, and updates migrations.
openHAB/UI/SettingsView/SettingsView.swift Reads/writes showSearchField from/to the active home preferences instead of application-level preferences.
openHAB/Models/SitemapPageViewModel.swift Loads showSearchField from the active home preferences when applying settings.

Comment thread OpenHABCore/Sources/OpenHABCore/Util/Preferences.swift Outdated
Comment on lines 152 to 155
// MARK: Retrieving preference from user defaults, reacting to preference change

// MARK: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

// MARK: !!

// MARK: When making changes to Preferences, always consider a migration for existing users. Otherwise, they risk to loose their existing preferences.

// MARK: !!

// MARK: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

private enum PreferencesAccess {
@MainActor fileprivate static func getPreference<T>(key: String, defaultValue: T, encoder: (T) -> (some Sendable)?, decoder: (Any?) -> T?) -> T {

Copilot AI Apr 7, 2026

Copy link

Choose a reason for hiding this comment

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

The prominent in-file warning about needing migrations when changing Preferences was removed, and there doesn’t appear to be an equivalent note elsewhere in the repo. Given that UserDefaultObject falls back to defaults (and overwrites stored data) when decoding fails, keeping a clear reminder near the preference schema helps prevent accidental preference loss. Consider restoring a shorter version of the warning here or moving it to a central contributor doc with a reference from this file.

Copilot uses AI. Check for mistakes.
@DigiH
DigiH force-pushed the settings branch 2 times, most recently from 3e8c13b to 2c04d7c Compare April 8, 2026 17:49
DigiH and others added 2 commits April 9, 2026 18:21
Signed-off-by: DigiH <17110652+DigiH@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Signed-off-by: DigiH <17110652+DigiH@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants