Skip to content

fix(shell): propagate immediate barConfig upon plugin settings update - #11888

Open
szaidi-code wants to merge 1 commit into
omacom:quattrofrom
szaidi-code:fix/shell-plugin-inline-settings-update
Open

szaidi-code wants to merge 1 commit into
omacom:quattrofrom
szaidi-code:fix/shell-plugin-inline-settings-update

Conversation

@szaidi-code

Copy link
Copy Markdown

Problem

When a shell plugin updates its inline settings via updateEntryInline(), persistShellConfig() writes the updated configuration to shellConfig. Because onShellConfigChanged fires immediately and synchronously prior to dependent property bindings (such as barConfig) re-evaluating, publicBarConfig() and barConfigFor() were returning stale configuration data from before the update. Consequently, plugins attempting to inspect or react to their updated settings received outdated state until an unrelated config change forced a re-render.

Additionally:

  • onBarConfigChanged updated internal bar state but failed to invoke shell.syncPluginApis().
  • Unlisted top-level plugins passed to updateEntryInline() were dropped if they had not yet been registered in shellConfig.plugins.

Fixes #11852

Solution

  1. Direct Configuration Resolution: Updated publicBarConfig() and barConfigFor() to resolve directly from shellConfig.bar (falling back to builtinShellConfig.bar), mirroring the direct property evaluation used elsewhere in shellRoot.
  2. Synchronize Injected APIs: Connected onBarConfigChanged to shell.syncPluginApis() so all loaded plugins immediately receive updated configuration state whenever the bar configuration shifts.
  3. Handle Top-Level Plugins: Allowed unlisted top-level plugins in updateEntryInline() to append to copy.plugins when absent from the layout, and clearly documented the boolean return contract.
  4. Automated Unit Tests: Added test/shell.d/plugin-settings-sync-test.sh validating structural AST hooks, immediate synchronized reads after updateEntryInline(), and no-op return semantics.

Verification

  • Ran ./test/shell.d/plugin-settings-sync-test.sh (8/8 pass).
  • Ran ./test/shell.d/bar-test.sh (80+/80+ pass).
  • Ran ./test/shell.d/plugins-test.sh (all pass).
  • Ran ./test/cli (100% pass).
  • Verified in isolated Arch Linux LXC test container environment.

Fixes omacom#11852

When a plugin updates its own settings with updateEntryInline(),
persistShellConfig() assigns shellConfig and immediately emits
onShellConfigChanged -> pluginsChanged() -> syncPluginApis(). Because QML
change handlers run before dependent property bindings re-evaluate,
publicBarConfig() was reading the stale barConfig property binding from
before the write, leaving the plugin with stale settings indefinitely.

1. Evaluate publicBarConfig() and barConfigFor() directly from the current
   shellConfig rather than the delayed barConfig binding.
2. In onBarConfigChanged, trigger shell.syncPluginApis() to guarantee all
   injected plugin APIs stay synchronized whenever barConfig updates.
3. In updateEntryInline(), allow unlisted top-level plugins to persist
   cleanly into shellConfig.plugins, and document that returning false
   indicates a no-op (identical settings already present).
4. Add test/shell.d/plugin-settings-sync-test.sh covering structural checks
   and immediate settings synchronization.
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.

Shell plugin never receives its own settings write: barConfig is published one write behind

1 participant