Repository navigation
Let windows follow the toolbar visibility preference - #4460
Merged
vogella merged 1 commit intoOct 13, 2026
Merged
Conversation
Contributor
Test Results 867 files 867 suites 47m 17s ⏱️ Results for commit f23ad41. ♻️ This comment has been updated with latest results. |
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.
vogella
force-pushed
the
toolbar-visibility-preference
branch
2 times, most recently
from
October 9, 2026 14:45
2872421 to
1ac5c78
Compare
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. This relies on the platform default being visible; a product that ships the bar hidden by default gets its restored windows pinned hidden. Assisted-by: multiple AI agents and layers of automated tooling 🤖
vogella
force-pushed
the
toolbar-visibility-preference
branch
from
October 13, 2026 04:49
1ac5c78 to
f23ad41
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.