Community
Participate
Working Groups
Part tab and tool bar colors/rendering are confusing since they lack a common concept. The colors are assigned seemingly random and don't convey semantics (active/inactive, foreground/background, cohesion between widgets of the active part). In 3.8, rendering was based on a few simple concepts: - active part is colorful, rest is gray - frontmost inactive editor tab is white (this was already a questionable choice) - view toolbars and menu/min/max have a normal widget background color (gray) In 4.2, I don't find similar concepts, but a lot of contradicting mixtures: - active part tab is white, but gets a gray gradient when part stack loses focus => why a gradient (attracting visual focus) when it is unfocused? - inactive part tab is - colorful when another tab in the same part stack is focused - white (with dimmed foreground) when a different part stack is focused => why different colors for inactive tabs? => why change the color of an inactive tab just because another tab in the same part stack gains/loses focus? => why is it white when white now means "active tab"? - the part toolbar background is - white for inactive parts => why is it white when white now means "active tab"? - gray gradient when part stack is active and tool bar fits on first line => why does the active tool bar have the same color as inactive part tabs? - white when part stack is active and tool bar wraps to second line => why does the active tool bar change colors? - In 3.0, a colored box was added around the active part to make it more visible. In 4.2, this feature is lost, but a large useless white border was added (bug 355949).
Initial discussions in: Bug 293481 - New look for e4 workbench PW
These issues have been resolved as the CSS mechanism has matured (Chrome theme...).
(In reply to Eric Moffatt from comment #2) > These issues have been resolved as the CSS mechanism has matured (Chrome > theme...). I can't see any of the reported problems resolved using N20131021-2000 on Windows 7 (theme).
*** Bug 374027 has been marked as a duplicate of this bug. ***
(In reply to Eric Moffatt from comment #2) > These issues have been resolved as the CSS mechanism has matured (Chrome > theme...). Are you talking about this?: https://github.com/jeeeyul/eclipse-themes#screen-shots I think this bug is about how Eclipse 4 looks by default, so it's a bit funny/sad to see one of the committers write that this is "resolved"..
Is it still valid after latest 'e4 default' theme updates? If so, could you please provide the major theme items to fix that will allow us to close the bug? Daniel
(In reply to Daniel Rolka from comment #6) > Is it still valid after latest 'e4 default' theme updates? If so, could you > please provide the major theme items to fix that will allow us to close the > bug? > > Daniel The bug is still present in N20140205-2000 (just read comment 0 again).
(In reply to Dani Megert from comment #7) > The bug is still present in N20140205-2000 (just read comment 0 again). Over the last years, we have done multiple enhancements in the CSS. If you still see improvements, please open a new bug (preferable with a Gerrit review).