Repository navigation
Conversation
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Legacy persisted visibility snapshots are misidentified as explicit overrides, preventing themes from controlling restored windows.
1 open finding
What changed in this PR
Updates workbench trim visibility so windows follow toolbar preferences while preserving explicit per-window choices.
Changes:
- Reacts to toolbar and perspective-bar preference changes.
- Persists only differing per-window choices.
- Adds UI tests for preference-following behavior.
| File | Description |
|---|---|
WorkbenchWindow.java |
Implements preference listeners and per-window overrides. |
TrimVisibilityPreferenceTest.java |
Tests trim preference and override behavior. |
InternalTestSuite.java |
Registers the new test class. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+2990
to
+2994
| String override = getModel().getPersistedState().get(key); | ||
| if (override == null) { | ||
| return preferred; | ||
| } | ||
| boolean visible = Boolean.parseBoolean(override); |
WorkbenchWindow copied coolBarVisible and perspectiveBarVisible into the window's persisted state at creation, so the preference was read once and never again, and themes had no way to hide the toolbar. The persisted state now holds a per-window choice only when the user toggles a window away from the preference, and that choice survives later preference changes. Windows without one follow the preference at runtime, so themes can set both keys through the IEclipsePreferences CSS element. Per-window toggling from bug 403461 keeps working. Values persisted by earlier versions are migrated: a hidden bar stays a per-window choice, a visible one was a copy of the preference and is dropped. Assisted-by: multiple AI agents and layers of automated tooling 🤖
vogella
force-pushed
the
toolbar-visibility-preference
branch
from
October 9, 2026 05:28
52e6cfc to
2872421
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Workbench windows copied the coolbar and perspective bar visibility preferences into their persisted state when they were created, so the preference was read once and never again. A theme therefore had no reliable way to hide the main toolbar: a widget rule on the trim bar is re-imposed on every styling pass and makes Window > Appearance > Show Toolbar silently revert.
Now the persisted state holds a per-window choice only when the user toggles a window away from the preference, and that choice survives later preference changes; windows without one follow the preference at runtime. Themes can set the visibility through the existing preference channel with
IEclipsePreferences#org-eclipse-ui-workbench:my-theme { preferences: 'coolBarVisible=false' 'perspectiveBarVisible=false'; }, where EclipsePreferencesHandler already arbitrates between theme and user values. Per-window toggling from bug 403461 keeps working. Values persisted by earlier versions are migrated, so a restored window does not pin a copied preference against the theme.