Match the conversation tab strip to Eclipse's real native colors - #106
Merged
eilonwy06 merged 4 commits intoSep 4, 2026
Merged
Conversation
The tab strip's active/inactive colors were inverted in light mode. The active tab and #toolbar/#convo-header both used --bg-soft, which in light mode (#f3f3f3) is DARKER than the page background --bg (#ffffff) — the opposite of dark mode, where --bg-soft (#232323) is lighter than --bg (#1e1e1e). --bg-soft itself isn't wrong (it's shared with cards, the composer, etc. where "distinct surface" rather than "lighter" is the correct read) — the tab strip needed its own tokens instead of reusing one calibrated for a different job. Adds --tab-bg / --tab-bg-active / --tab-hover-preview / --chrome-hover, with dark's values chosen to reproduce today's look exactly (a pure rename, not a value change) and light's chosen so the active tab is unambiguously the lightest thing in the strip, matching the content pane it opens into — both rows now read as chrome sitting above that pane, not blended into it.
…uess tokens.css's --tab-bg / --tab-bg-active values (from the previous commit) are still a guess at each platform's native chrome gray — authored without a GTK display to verify against, so #ececec might not actually match any given user's theme. This replaces the guess with the real thing where possible: ClaudeGuiView.findEditorAreaTabColors locates the editor area's actual CTabFolder via the E4 model (EModelService.find(ID_EDITOR_AREA, ...) -> MPlaceholder -> MPartStack -> its SWT widget) and reads its getBackground()/getSelectionBackground() directly — the same setters E4's theme engine calls, so no CSS-engine round-trip is needed. pushTheme() passes these as optional 2nd/3rd args to onTheme(), which sets them as inline styles on :root (winning over both :root and :root.light in the cascade). Falls back to the last successfully sampled colors when the editor area is momentarily unreachable (e.g. zero editors open), and to tokens.css's static values when nothing has ever been sampled — so a missing/unusual Eclipse layout degrades to the previous commit's guess rather than breaking. Deliberately targets the EDITOR area specifically, not wherever this view itself happens to be docked: Eclipse's view-stack and editor-stack active- tab styling differ, and the editor style is the one this webview's tab strip is designed to visually match. Logs the sampled hex pair (+ light/dark mode) via Activator.log when Debug mode is on, so the actual GTK values can be read back from the Error Log view without needing a GTK display to develop against.
…needs findEditorAreaTabColors (previous commit) uses EModelService, MApplication, MUIElement, MPlaceholder, and MPartStack, but MANIFEST.MF never declared Require-Bundle entries for the bundles that export them (org.eclipse.e4.ui.workbench for EModelService, org.eclipse.e4.ui.model.workbench for the MUIElement family). OSGi refused to resolve the classes at runtime — NoClassDefFoundError: org/eclipse/e4/ui/model/application/ui/MUIElement — which crashed ClaudeGuiView's instantiation entirely (a working javac pass never caught this: it compiles with every installed plugin jar on one flat classpath, which hides OSGi package-visibility rules). The specific packages used (org.eclipse.e4.ui.model.application.ui and its .advanced/.basic children) are plain Export-Package entries with no x-friends/x-internal restriction, so this is a normal public dependency, not discouraged access.
IPageLayout.ID_EDITOR_AREA resolves (via the MPlaceholder it's wrapped in) to an MArea — the editor area's container — not directly to the MPartStack that renders the actual tab folder. The previous code assumed MPartStack and silently fell back to "unavailable" on every real Eclipse session. Fix by checking for MArea, then using EModelService.findElements to search its MPartStack descendants, preferring the one tagged org.eclipse.e4.primaryDataStack (falls back to the first live CTabFolder-backed stack for split-editor layouts on older/newer E4 versions that might not tag it). Also removes the now-unneeded dumpTabFolders() debug helper, and updates tokens.css's light-theme fallback colors from a guess (#ececec) to the real value a live GTK CTabFolder reports (#f8f8f8) — these tokens are now only the fallback for when dynamic sampling fails, e.g. no editors open yet at startup.
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
2 participants
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.
Reads the actual colors of Eclipse's own editor tab strip at runtime and uses them for the conversation tab strip. Also fixes a bug where those colors came out inverted under a light color theme.
Makes the panel blend into whichever Eclipse theme, OS, or desktop environment someone is running.