Bug 378672 - [CSS] Part tab and tool bar colors/rendering are confusing
Summary: [CSS] Part tab and tool bar colors/rendering are confusing
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 4.2   Edit
Hardware: All All
: P3 major with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard: candidate43
Keywords: usability
: 374027 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-05-07 10:19 EDT by Markus Keller CLA
Modified: 2016-05-12 05:08 EDT (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2012-05-07 10:19:16 EDT
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).
Comment 1 Paul Webster CLA 2012-05-07 10:51:44 EDT
Initial discussions in:
Bug 293481 - New look for e4 workbench

PW
Comment 2 Eric Moffatt CLA 2013-10-21 14:06:51 EDT
These issues have been resolved as the CSS mechanism has matured (Chrome theme...).
Comment 3 Dani Megert CLA 2013-10-22 08:27:16 EDT
(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).
Comment 4 John Arthorne CLA 2013-11-11 09:00:53 EST
*** Bug 374027 has been marked as a duplicate of this bug. ***
Comment 5 Robin Stocker CLA 2013-11-29 10:48:42 EST
(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"..
Comment 6 Daniel Rolka CLA 2014-02-05 10:00:42 EST
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
Comment 7 Dani Megert CLA 2014-02-06 08:28:55 EST
(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).
Comment 8 Lars Vogel CLA 2016-05-12 05:08:53 EDT
(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).