Bugzilla – Full Text Bug Listing
|
Description
Dani Megert
Dani, is this the same problem as bug 320894 or is this a slightly different variant? (In reply to comment #1) > Dani, is this the same problem as bug 320894 or is this a slightly different > variant? I was a aware of that bug. Looking closer they are indeed different but bug 3208934 is not restricted to editors. I've update the bug accordingly. This is still one of the bugs that makes me not use 4.1. (In reply to comment #3) > This is still one of the bugs that makes me not use 4.1. Me too. IMHO working fluently with the workbench requires that finding which part is active must not consume more than very few milliseconds of your brain. You shouldn't ever be aware of this kind of question. Emphasis by coloring the inactive portion of the tab bar of the active part requires that you actually think about it. Keep in mind that this inactive portion of the tab bar can be smaller than the active tab. For finding the active part you do not want to actively search for inactivate tab bar areas. Please consider either: - using a dedicated color for the active thing (active tab within active part) - or: paint significantly different borders, e.g., 3-D effect only for the active part, other parts are strictly flat on the background. E.g., KDE has this "glow" around the active window, which works well to attract the eyes. No progress here? 4.2 milestones still don't look convincing. Desperate to get some useful emphasis back I tried to change the preference back to 3.x values. Much to my surprise the preferences seem to "believe" that I still HAVE a 3.x Eclipse. (General > Appearance > Colors and Fonts > View and Editor Folders). If proper emphasis is not the default that's a regression, if configuration options are out of sync with the implementation I'm all at loss. Please: The current scheme requires the user to actively think in indirections: I'm looking at a tab in a stack: it's white, what does it tell me? Nothing, tabs in all stacks are white. Is it active? Look at the those parts of the tab-bar that you are NOT looking at! Do they have a different color than all the other not-looked-at parts of tab-bars? Yes? Mind you: that's way too much indirection and negation doesn't work well unconsciously. Pretty please, give back a one-stop info. This is still one of the bugs that makes me not use 4.2 on a regular basis. Bogdan, is there any CSS mechanism through which to specify the color of the tab item for the active part ? Personally I don't find this confusing but I've been using it for a long time... This is probably controlled by the basestyle followed by the platform stylesheet.
base:
.MPartStack {
swt-tab-renderer: url('bundleclass://org.eclipse.e4.ui.workbench.renderers.swt/org.eclipse.e4.ui.workbench.renderers.swt.CTabRendering');
swt-unselected-tabs-color: #FFFFFF #FFFFFF #FFFFFF 100% 100%;
swt-outer-keyline-color: #FFFFFF;
swt-inner-keyline-color: #FFFFFF;
padding: 0px 9px 10px;
swt-tab-outline: #B6BCCC;
swt-shadow-visible: true;
swt-mru-visible: false;
}
.MPartStack.active {
swt-inner-keyline-color: #FFFFFF;
swt-tab-outline: #B6BCCC;
swt-shadow-visible: true;
}
gtk:
.MPartStack.active {
swt-unselected-tabs-color: #DCDCDC #E1E1E1 #FFFFFF 100% 100%;
swt-outer-keyline-color: #B4B4B4;
swt-tab-outline: #B4B4B4;
}
Created attachment 213885 [details]
Picture showing active tab not recognizable
Given the active part is more important, its tab
should also be more eye-catching that inactive ones. Maybe it's just me, but
the gray-shaded tabs jump much faster to my eyes than the white one.
I would be willing to close this as being a matter of taste, but only if bug
355946 got fixed.
Given bug 355946, the current look is a pain for me. Can you please reconsider to fix this for 4.2? (In reply to comment #10) > Given bug 355946, the current look is a pain for me. Can you please reconsider > to fix this for 4.2? Or bug 355946. Bug 378672 also explains the lack of consistency in the E4 themes. Do you have any suggestions how to mark the active part? Do you want to have any specific background color or any specific border? I would use some the specific border color since it won't introduce the major change in the 'e4 default' layout and it should be smoothly accepted by the users, IMHO Daniel (In reply to Daniel Rolka from comment #13) > Do you have any suggestions how to mark the active part? Do you want to have > any specific background color or any specific border? In the old 3.x theme the active part is easy to detect because it has - colored background of the tab - border around the entire part in the same color I'm not particular keen on any specific color as long as it can be easily distinguished from the rest. So, why not re-adopt what has worked just fine in the past? :) (BTW I didn't quite understand your proposal grammatically, so not sure if you're actually proposing the same) Created attachment 241426 [details] Modified E4 default theme (In reply to Stephan Herrmann from comment #14) > (In reply to Daniel Rolka from comment #13) > > Do you have any suggestions how to mark the active part? Do you want to have > > any specific background color or any specific border? > > In the old 3.x theme the active part is easy to detect because it has > - colored background of the tab > - border around the entire part in the same color > I'm not particular keen on any specific color as long as it can be easily > distinguished from the rest. > Do you want to get the following effect: 'Modified E4 default theme'? > So, why not re-adopt what has worked just fine in the past? :) I'm not sure if we want to copy the entire 'classic' theme to the 'E4 default' one > > (BTW I didn't quite understand your proposal grammatically, so not sure if > you're actually proposing the same) The 'E4 default' theme has got the specific color scheme and I would like to solve the current issue following it. I don't want to introduce major changes in the theme - for me replacing the 'white' background of the active part with other color is the major change. From my point of view adding some border that will help the user distinguish the active part is better option (the current 'blue' background of the inactive parts seems to be insufficient) Daniel (In reply to Daniel Rolka from comment #15) > Created attachment 241426 [details] > Modified E4 default theme This makes it even harder to see the active tab in the active part stack (e.g. if you have many editors open). These theming problems cannot be resolved one-by-one, since all colors depend on each other, and whenever you change one color, you break other constraints. The only way out of the misery is to define a few core concepts and then stick to them. See bug 378672. (In reply to Markus Keller from comment #16) > (In reply to Daniel Rolka from comment #15) > > Created attachment 241426 [details] > > Modified E4 default theme > > This makes it even harder to see the active tab in the active part stack > (e.g. if you have many editors open). > > These theming problems cannot be resolved one-by-one, since all colors > depend on each other, and whenever you change one color, you break other > constraints. The only way out of the misery is to define a few core concepts > and then stick to them. See bug 378672. All colors used by the 'E4 default' theme are exposed in the preference page. Are you able to modify the theme as you think it should look and attach the proper screenshot? When we all agree with the new color palette I will update the CSS files with the new default values. thanks for help, Daniel (In reply to Daniel Rolka from comment #15) > > So, why not re-adopt what has worked just fine in the past? :) > > I'm not sure if we want to copy the entire 'classic' theme to the 'E4 > default' one I wasn't suggesting to copy all aspects of the classic scheme, just the aspect relating to highlighting of the active part. :) I think the only way leading us out of a discussion of personal preferences is to really do a little usability experiment along the following lines: - start with 3-5 draft theme proposals - create 10-20 different screenshots in each variant (for all IDE situations) - pick 3-5 test persons, for each: - present the screenshots in sequence - let test person name the active part as quickly as s/he can - measure total time for all screenshots, milleseconds are relevant ... I believe, when drafting a proposal, one should take the freedom to modify other aspects of the theme as well, because the contrast (brightness & color) matters, not the color by itself. Created attachment 241678 [details]
Active part with border
Created attachment 241679 [details] Active part with gradient (In reply to Daniel Rolka from comment #17) > (In reply to Markus Keller from comment #16) > > (In reply to Daniel Rolka from comment #15) > > > Created attachment 241426 [details] > > > Modified E4 default theme > > > > This makes it even harder to see the active tab in the active part stack > > (e.g. if you have many editors open). > > > > These theming problems cannot be resolved one-by-one, since all colors > > depend on each other, and whenever you change one color, you break other > > constraints. The only way out of the misery is to define a few core concepts > > and then stick to them. See bug 378672. > > All colors used by the 'E4 default' theme are exposed in the preference > page. Are you able to modify the theme as you think it should look and > attach the proper screenshot? When we all agree with the new color palette I > will update the CSS files with the new default values. > > thanks for help, > Daniel I would like to propose the following solutions for the issue: - marking the active part with border - 'Active part with border' - marking the part with the 'classic' like gradient - 'Active part with gradient' Daniel (In reply to Daniel Rolka from comment #19) > Created attachment 241678 [details] > Active part with border -1. The thin colorful border looks like a rendering issue. The 1px line is too intrusive and the rounded corners look jagged because there's no anti-aliasing. (In reply to Daniel Rolka from comment #20) > Created attachment 241679 [details] > Active part with gradient This looks better, but it's hard to tell from the screenshot how easy it is to find the active editor tab if you have many editors open. (That's already hard today if the workbench window doesn't have focus.) Created attachment 241712 [details] Active editor with gradient (In reply to Markus Keller from comment #21) > This looks better, but it's hard to tell from the screenshot how easy it is > to find the active editor tab if you have many editors open. I've attached the snapshot with the active editor - 'Active editor with gradient' (That's already > hard today if the workbench window doesn't have focus.) We have the support for the active and without focus parts in the 'e4 default' theme, but by default it is rendered as the active parts. We have to just define better colors for this state (the 'classic' ones don't match here) Daniel Do you agree with the following proposals: Created attachment 241679 [details] Active part with gradient Created attachment 241712 [details] Active editor with gradient and I can update the 'e4 default' themes with the new default colors? Daniel (In reply to Daniel Rolka from comment #23) > Do you agree with the following proposals: > > and I can update the 'e4 default' themes with the new default colors? My e4 default is all greys, whites, and gradients. But that's GTK. What is it supposed to look like on GTK? PW Created attachment 242014 [details] The CSS style sheet used to generate the active part/editor with gradient (In reply to Paul Webster from comment #24) > (In reply to Daniel Rolka from comment #23) > > Do you agree with the following proposals: > > > > and I can update the 'e4 default' themes with the new default colors? > > My e4 default is all greys, whites, and gradients. But that's GTK. What is > it supposed to look like on GTK? > > PW For me the new colors are fine on the GTK. Are you able to confirm it using the style sheet - 'The CSS style sheet used to generate the active part/editor with gradient'? I don't know if it is fine on the Mac OS Daniel Created attachment 242015 [details]
Package explorer with jarring bluw, attached CSS
This changes the colors on GTK and is quite jarring (and deviates significantly from the default e4 style).
The blue isn't part of the e4 color pallete on linux at all.
Also, activating a non-eclipse window gets rid of the blue completely.
PW
Created attachment 242016 [details]
Package explorer current
Created attachment 242017 [details]
Type hierarchy with jarring blue, attached CSS
Created attachment 242018 [details]
Type hierarchy current
OK, so we can focus on Windows now and prepare the separate patches for the GTK as well as the Mac OS Daniel Looks like a bug in the E4 themes that the "Active part background end" color bleeds into the wrapped view toolbar and even into the view background. This doesn't happen in Classic themes. (In reply to Markus Keller from comment #31) > Looks like a bug in the E4 themes that the "Active part background end" > color bleeds into the wrapped view toolbar and even into the view > background. This doesn't happen in Classic themes. Yes, see bug 430872. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=87ce6024139c8ae949d7fe5c33a417ab2c3e4c0b We can still further improve the details during RC1. (In reply to Dani Megert from comment #32) > (In reply to Markus Keller from comment #31) > > Looks like a bug in the E4 themes that the "Active part background end" > > color bleeds into the wrapped view toolbar and even into the view > > background. This doesn't happen in Classic themes. > > Yes, see bug 430872. > > > Fixed with > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=87ce6024139c8ae949d7fe5c33a417ab2c3e4c0b > > We can still further improve the details during RC1. I've reverted that change, see bug 330117 comment 31 for more details. Created attachment 256755 [details]
Proposal 20150922-1 : reverse part colors
This proposal is reversing settings of enabled/disabled parts in order to put more "light" on the active part and soften colors for inactive parts.
Created attachment 256756 [details]
Proposal 20150922-2: white + 2 shades of grey
This second proposal introduce a new grey in order to have only 1 tab, the active one on the active part, using white.
*** Bug 478050 has been marked as a duplicate of this bug. *** Created attachment 256757 [details] Jeeyul's Chrome Theme > I had to read the comments few times to get an idea which tab is selected > finally for last screenshot (Git Staging???). Neither the default nor the > proposal are working for me is I wear "stupid user" hat. And is the proposal better? I have more confidence in our (Platform/UI interested parties) ability to propose and implement small improvement and iterate than in our ability to agree on one good solution within a year. > Could you please > post here the Jeeyul's Chrome theme screenshot, so that we have an idea how > it could look like in a "better" IDE? Here it is. > So if this helps, we should fix this bug and bug 325937 by introducing a > clearly recognizable "active part" color which is NOT white NOR grey but > something anyone can easily identify - might be "lighter" eclipse blue color. I believe you'll like Jeeyul's theme (and there are several very good ones, more usable than default Eclipse one) Most of us are probably well aware of this; some but not all proposals seem to adhere to it: Human vision recognizes brilliant colors with high contrast as proximity, things to pay attention to right now. Mist, blur, weaker colors, darker colors, smaller size, those signal distance and things that can be ignored right now. Let's make sure "active" is perceived as "close by", "inactive" as "distant" and all will be fine. (In reply to Stephan Herrmann from comment #38) > Most of us are probably well aware of this; some but not all proposals seem > to adhere to it: Amongst the recent proposal, is there one that you think would make a first iteration on the right direction, compared to actual theme? (In reply to Mickael Istria from comment #35) > Created attachment 256756 [details] > Proposal 20150922-2: white + 2 shades of grey > > This second proposal introduce a new grey in order to have only 1 tab, the > active one on the active part, using white. +1. Looks good. Just wondering what (visually) would happen if we give it a 1 pixel border (with some blueisch Eclipse color)? (In reply to Andrey Loskutov from comment #40) > (In reply to Mickael Istria from comment #35) > > Created attachment 256756 [details] > > Proposal 20150922-2: white + 2 shades of grey > > This second proposal introduce a new grey in order to have only 1 tab, the > > active one on the active part, using white. > +1. Looks good. Just wondering what (visually) would happen if we give it a > 1 pixel border (with some blueisch Eclipse color)? I pushed the suggested CSS for the 2nd proposal on https://git.eclipse.org/r/56418 . However, since I don't feel very easy with e4 CSS, I didn't go further and didn't try to add a border for selected tab. Sonce the proposal on Gerrit implementing attachment 256756 [details] seems to be an improvement over current status, I'm setting a target to 4.6.M3 hoping this can be reviewed and merge as a step forward.
Created attachment 257219 [details] 56418/3: active part tab presentation with opened modal dialog on win 10 (In reply to Mickael Istria from comment #42) > Sonce the proposal on Gerrit implementing attachment 256756 [details] seems > to be an improvement over current status, I'm setting a target to 4.6.M3 > hoping this can be reviewed and merge as a step forward. Mickael, after trying the new theme on Windows 10 (unfortunately I have no other PC at the moment), I've noticed a small issue: the currently selected and active part appearance changes if one open a dialog, see attached picture. Since the new theme has no gradient, but this "active inactive" tab has a gradient, it looks strange. I'm not sure if this is intended or not (the old theme didn't changed tab appearance with opened dialog), but my feeling is that in this case the appearance shouldn't change. Thanks for trying the patch and noticing this issue Andrey. Indeed, it seems to be something important to improve before merging the patch. I'll do my best to fix that, but since I'm not good at e4 CSS, any help would be highly welcome! @Andrey: your screenshot seems to show that you have Jeeyul's Chrome Theme installed while trying the patch. Is that the case? Can you please try without it? (In reply to Mickael Istria from comment #45) > @Andrey: your screenshot seems to show that you have Jeeyul's Chrome Theme > installed while trying the patch. Is that the case? Can you please try > without it? No, I do not use it. Usually I do not have theming enabled at all, but if I do, I use "pure" Eclipse. Ok, got it. I got confused because the default color on Windows seems to be a similar blue as Jeeyul's Chrome theme. Created attachment 257896 [details]
Proposal in Patch Set #6
I uploaded the suggested Gerrit review to include changes suggested by Andrey about keeping same color of the active selected tab with or without focus (current behaviour in Mars.1). I also changed the shade of gray by a mix of blue and gray that was already referenced in the CSS.
I like the result (see attached screenshot).
Created attachment 258203 [details]
active/inactive part/stack color proposal
I was asked to comment on patch #7 regarding this issue. While it succeeds to improve the discriminability of the active/inactive part/stack I find the overall color scheme less appealing as the one of the original theme. This attachment shows a solution that keeps most of the active part/stack color settings of patch 7 but increases the outline contrast of active and inactive stacks. Plus, it works with decent shades of the active-non-selected tab color for the inactive part/stack elements. One first sight this seems a neat compromise to me - what do you think?
Created attachment 258204 [details] Patch for attachment 258203 [details] Patch for attachment 258203 [details] (In reply to Frank Appel from comment #49) > Created attachment 258203 [details] > active/inactive part/stack color proposal > > I was asked to comment on patch #7 regarding this issue. While it succeeds > to improve the discriminability of the active/inactive part/stack I find the > overall color scheme less appealing as the one of the original theme. This > attachment shows a solution that keeps most of the active part/stack color > settings of patch 7 but increases the outline contrast of active and > inactive stacks. Plus, it works with decent shades of the > active-non-selected tab color for the inactive part/stack elements. One > first sight this seems a neat compromise to me - what do you think? Frank, the result looks great (the theme in overall is not for my taste because of the colored toolbars, but this is not the point here). Two things: 1) Can you provide a gerrit patch? 2) Can you provide a Linux GTK version? Some comments about Franz's proposal. Most also applies to the current CSS: * The selected part stack (whole stack, not tab) is darker than the not selected one. So it makes that the unselected part stack is literally highlighted compared to the inactive one * On GTK3, I tried the patch and I didn't see a clear improvement over current status. There is still white on the inactive stacks, and a lot of light is put everywhere, making it difficult to identify context at first sight * In general, the use of gradients seem to be an anti-pattern: indeed, gradients give an impression of relief and make the tabs with gradient feel like they are a bit above all the others without gradient. As we already are using colors and light to express the distance and focus for tabs, having also gradients makes that we use 2 metaphors for the same thing, with conflicting results. Like most of the applications I'm using, both web and desktop, Eclipse IDE should probably avoid gradients. So IMO, this issue is mainly about removing the gradients, and making sure that the more an item is active, the lighter it is. So I published a patch set 8 on Gerrit which is removing gradients (similar to patch set 6 which has screenshot attached, but with a shade of grey instead of a blue-ish one). In my opinion, it's comfortable to use and fixes the initial issue about detected active part/stack. About the palette of colors, it would be better to discuss it in another bug since it's a related but different topic. (In reply to Mickael Istria from comment #52) > Some comments about Franz's proposal. Most also applies to the current CSS: > * The selected part stack (whole stack, not tab) is darker than the not > selected one. So it makes that the unselected part stack is literally > highlighted compared to the inactive one > * On GTK3, I tried the patch and I didn't see a clear improvement over > current status. There is still white on the inactive stacks, and a lot of > light is put everywhere, making it difficult to identify context at first > sight > * In general, the use of gradients seem to be an anti-pattern: indeed, > gradients give an impression of relief and make the tabs with gradient feel > like they are a bit above all the others without gradient. As we already are > using colors and light to express the distance and focus for tabs, having > also gradients makes that we use 2 metaphors for the same thing, with > conflicting results. Like most of the applications I'm using, both web and > desktop, Eclipse IDE should probably avoid gradients. > So IMO, this issue is mainly about removing the gradients, and making sure > that the more an item is active, the lighter it is. > > So I published a patch set 8 on Gerrit which is removing gradients (similar > to patch set 6 which has screenshot attached, but with a shade of grey > instead of a blue-ish one). In my opinion, it's comfortable to use and fixes > the initial issue about detected active part/stack. > > About the palette of colors, it would be better to discuss it in another bug > since it's a related but different topic. I see what you mean by the similarities, but given it a second thought I actually can't follow the initial statement of this issue. I clearly perceive the outline view as the active part in the attachment 213885 [details]. So probably it's no wonder why my proposal has similarities to the original theme. Which raises the question (at least for me) whether this issue is indeed observed as a problem by the majority of the users. So, let me share some reasoning on this. What I tried to achieve was to intensify the contrasts to emphasize the active part even more. This is because from what I understand of color theory, emphasizing has more to do with contrasts than simply putting some light or dark colors on UI elements (I deliberately avoid the term highlighting here). Putting a darker color or black around a box of light color, for example, emphasizes the box content much more because it appears brighter. Looking at the original theme screenshot from that point of view, the outline view tab is the most prominent element of the workbench parts, which is a clear signer that it reflects the active part of the conceptual model - I can't follow the argument of the issue creator here, which shows how different the perception of people can be. The relief effect of the gradient, as you named it, actually reduces the contrast and makes the element less prominent. But, while I doubt the theory of conflicting results, I can see that the gradient might be a bit of an alien element as it isn't used on other parts of the UI. However, considering the steering effects of colors, in general, I'm skeptical of the idea to separate the decision about the color palette from this topic. But since I'm far from being a professional designer there is a good chance that I got it all wrong - so it might be a good idea to ask a pro for help ;-) Created attachment 258219 [details]
PatchSet #8 vs Current (GTK3)
Attached screenshot shows the current status of Eclipse IDE on GTK3 (on the right) vs current proposed patch set 8 (on the left).
To me, it seems obvious that the proposal is a step towards fixing the issue of detecting the active tab more easily. I wouldn't say it's perfect, but at least, it works and it can be a 1st iteration. WDYT (Franz, Andrey and other interested parties)? Note that for the sake of actual progress, the question isn't really "how could it be better?", but more "is it actually better and should it be merged as a valid solution for the reported issue?".
I just checked competiting IDEs, and IJ uses a similar approach of flat, no gradient, tabs with white/light grey + 2 shades of grey ; and NB uses a specific color (light blue) for the selected tab where all other tabs are in 2 shades of grey.
(In reply to Mickael Istria from comment #54) > Created attachment 258219 [details] > PatchSet #8 vs Current (GTK3) > > Attached screenshot shows the current status of Eclipse IDE on GTK3 (on the > right) vs current proposed patch set 8 (on the left). > To me, it seems obvious that the proposal is a step towards fixing the issue > of detecting the active tab more easily. I wouldn't say it's perfect, but at > least, it works and it can be a 1st iteration. WDYT (Franz, Andrey and other > interested parties)? Note that for the sake of actual progress, the question > isn't really "how could it be better?", but more "is it actually better and > should it be merged as a valid solution for the reported issue?". > > I just checked competiting IDEs, and IJ uses a similar approach of flat, no > gradient, tabs with white/light grey + 2 shades of grey ; and NB uses a > specific color (light blue) for the selected tab where all other tabs are in > 2 shades of grey. I definitively agree that the color scheme on GTK is an improvement (given my explanations about contrast above I still would give it a try to use a darker shade of gray for the inactive tab of the active part stack than the one for the inactive tab of the inactive part stack. Well, but as you said that might not be the focus here). However, given that the windows theme uses a color scheme based on shades of blue, comparison with other applications that are based on shades of gray may not be appropriate. So from the point of the windows theme, the latest patch isn't an improvement, it simply looks broken. But maybe there is something broken indeed (only with my checkout?) because the inactive tabs of the inactive parts show a gray gradient. If I understand your previous remarks correctly, you would prefer to avoid any gradients, right? (In reply to Mickael Istria from comment #54) > Created attachment 258219 [details] > PatchSet #8 vs Current (GTK3) > > Attached screenshot shows the current status of Eclipse IDE on GTK3 (on the > right) vs current proposed patch set 8 (on the left). > To me, it seems obvious that the proposal is a step towards fixing the issue > of detecting the active tab more easily. I wouldn't say it's perfect, but at > least, it works and it can be a 1st iteration. WDYT (Franz, Andrey and other > interested parties)? Note that for the sake of actual progress, the question > isn't really "how could it be better?", but more "is it actually better and > should it be merged as a valid solution for the reported issue?". > > I just checked competiting IDEs, and IJ uses a similar approach of flat, no > gradient, tabs with white/light grey + 2 shades of grey ; and NB uses a > specific color (light blue) for the selected tab where all other tabs are in > 2 shades of grey. I definitively agree that the color scheme on GTK is an improvement (given my explanations about contrast above I still would give it a try to use a darker shade of gray for the inactive tab of the active part stack than the one for the inactive tab of the inactive part stack. Well, but as you said that might not be the focus here). However, given that the windows theme uses a color scheme based on shades of blue, comparison with other applications that are based on shades of gray may not be appropriate. So from the point of the windows theme, the latest patch isn't an improvement, it simply looks broken. But maybe there is something broken indeed (only with my checkout?) because the inactive tabs of the inactive parts show a gray gradient. If I understand your previous remarks correctly, you would prefer to avoid any gradients, right? Created attachment 258220 [details]
dark themed Idea and VS 2015 side-by-side
Here's a side by side comparison of IDEA 15 and Visual Studio 2015. VS uses a striking blue focus color for currently active part stack. In general its theme is really very good.
IDEA uses a weak nondescript blueish grayish focus color for active parts, which you can barely see from few steps away. Oh, IDEA also has something called scopes for files which in practice means code editor tabs don't get any focus color when they are active. A bit weird. I picked a color I'd used earlier and it's not really getting it...
Since the UI styles are quite different between Windows (which uses shades of blue and gradients) and GTK (shades of grey, flat) applications, this requires specific changes for Windows and GTK. Frank Appel and I have collaborated on a patch that was submitted as a new patch set on https://git.eclipse.org/r/#/c/56418/ . We believe that this is a good solution for this issue, on both systems. (In reply to Mickael Istria from comment #58) > Frank Appel and I have collaborated on a patch that was submitted as a new > patch set on https://git.eclipse.org/r/#/c/56418/ . We believe that this is > a good solution for this issue, on both systems. I had hard time to see differences on Windows but commit message helped finally. +1. Gerrit change https://git.eclipse.org/r/56418 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=88c5aba15dc5a16b66b331b2d072499da9065d37 Thanks everyone! I'm very pleased of the GTK fix, and the Windows change seems good too (although I didn't try in action). Is there anything to add on this topic or can we mark this issue as resolved? Would it be possible to backport it to maintenance branch? What's the policy regarding theme changes? (In reply to Mickael Istria from comment #62) > Would it be possible to backport it to maintenance branch? What's the policy > regarding theme changes? -1. We only backport critical fixes not enhancements (In reply to Lars Vogel from comment #63) > (In reply to Mickael Istria from comment #62) > > Would it be possible to backport it to maintenance branch? What's the policy > > regarding theme changes? > > -1. We only backport critical fixes not enhancements Correct, and we avoid UI tweaking changes in service releases. Same applies to strings shown in the UI. Adopters and products often produce documentation and screenshots based on the release and don't expect to have to change that for a service release. In addition, they might have set colors for their UI based on what we deliver with the release theme(s). (In reply to Mickael Istria from comment #61) > Thanks everyone! I'm very pleased of the GTK fix, and the Windows change > seems good too (although I didn't try in action). On Windows 7 with a new workspace I cannot really see a difference between 4.5 and N20151129-1300. (In reply to Dani Megert from comment #65) > (In reply to Mickael Istria from comment #61) > > Thanks everyone! I'm very pleased of the GTK fix, and the Windows change > > seems good too (although I didn't try in action). > > On Windows 7 with a new workspace I cannot really see a difference between > 4.5 and N20151129-1300. I just checked the build on windows and verified that the changes have been applied. It's only a small evolution of the original default theme, but it should make the active tab of the active stack a bit more prominent by reducing the contrast of the inactive stack elements - without disrupting the accustomed L&F. Maybe the win related commit message helps: On Windows: * reduce contrast on inactive tab gradient * reduce contrast between inactive tab and unselected inactive tabs by the use of a light blue background color Or did you notice these changes but think they do not work out well or they are not enough? Marking as fixed as we have some improvements, please reopen or open a new bug, if there is still work to be done. (In reply to Lars Vogel from comment #67) > Marking as fixed as we have some improvements, please reopen or open a new > bug, if there is still work to be done. I filed this bug and just commented a day ago that it is not fixed for me, so, closing this is not OK. Created attachment 258385 [details] 4.5 vs. N20151129-1300 (In reply to Frank Appel from comment #66) > (In reply to Dani Megert from comment #65) > > (In reply to Mickael Istria from comment #61) > > > Thanks everyone! I'm very pleased of the GTK fix, and the Windows change > > > seems good too (although I didn't try in action). > > > > On Windows 7 with a new workspace I cannot really see a difference between > > 4.5 and N20151129-1300. > > I just checked the build on windows and verified that the changes have been > applied. It's only a small evolution of the original default theme, but it > should make the active tab of the active stack a bit more prominent by > reducing the contrast of the inactive stack elements - without disrupting > the accustomed L&F. Maybe the win related commit message helps: > > On Windows: > * reduce contrast on inactive tab gradient > * reduce contrast between inactive tab and unselected inactive tabs by the > use of a light blue background color > > Or did you notice these changes but think they do not work out well or they > are not enough? I didn't really notice any change that jumped into my eyes. See attached picture that shows 4.5 (left) and N20151129-1300 (right), with the Problems view being the active part. (In reply to Dani Megert from comment #69) > Created attachment 258385 [details] > 4.5 vs. N20151129-1300 > > (In reply to Frank Appel from comment #66) > > (In reply to Dani Megert from comment #65) > > > (In reply to Mickael Istria from comment #61) > > > > Thanks everyone! I'm very pleased of the GTK fix, and the Windows change > > > > seems good too (although I didn't try in action). > > > > > > On Windows 7 with a new workspace I cannot really see a difference between > > > 4.5 and N20151129-1300. > > > > I just checked the build on windows and verified that the changes have been > > applied. It's only a small evolution of the original default theme, but it > > should make the active tab of the active stack a bit more prominent by > > reducing the contrast of the inactive stack elements - without disrupting > > the accustomed L&F. Maybe the win related commit message helps: > > > > On Windows: > > * reduce contrast on inactive tab gradient > > * reduce contrast between inactive tab and unselected inactive tabs by the > > use of a light blue background color > > > > Or did you notice these changes but think they do not work out well or they > > are not enough? > > I didn't really notice any change that jumped into my eyes. See attached > picture that shows 4.5 (left) and N20151129-1300 (right), with the Problems > view being the active part. Ok, seems as if you're expecting something different. Sorry that it didn't work out, but I'm running out of ideas. Maybe someone else can come up with a better approach. I believe the approach used for the GTK Theme (Flat tabs without gradient, white and light colors for the active part and darker for the inactive ones) would work well on Windows too. (In reply to Frank Appel from comment #70) > Ok, seems as if you're expecting something different. Can you see any real difference in my attached picture? Some other software with a blueish theme (such as visual studio) use some yellow/orange as background or underline for the active tab. Maybe we could simply adopt it for Eclipse IDE on Windows? (In reply to Mickael Istria from comment #73) > Some other software with a blueish theme (such as visual studio) use some > yellow/orange as background or underline for the active tab. Maybe we could > simply adopt it for Eclipse IDE on Windows? No, that would be too intrusive and not fit into the blue theme. Just take a look how it was done in 3.8.2: everything was grey except for the active part tab, which was blue (similar color as the active window title bar). Created attachment 258940 [details]
what is the active editor / view?
I'm not 100% sure if this is caused by the change here, but since recently I started spending time in guessing which editor I'm currently looking at, when the editor stack doesn't have focus (see attached screenshot).
Similar for the bottom stack: where do I have to click to close the history view?
Feels like a regression to me.
Seen in I20151222-0800 running on Kubuntu 15.10 with SWT_GTK3=0.
The same lack of difference can be observed on GKT3, too.
The following seems to be the best way to figure out which editor/view in an inactive stack is shown: hover over all the tabs in the stack, the one that is *not* highlighted (white background) during hover, is the visible one, outch.
Since in this bug we are discussing how to de-emphasize inactive parts, I'd like to suggest to mark the visible editor / view by a stronger outline around the tab, rather than continued fiddling with tab colors.
(In reply to Stephan Herrmann from comment #75) > Created attachment 258940 [details] > what is the active editor / view? > > I'm not 100% sure if this is caused by the change here, but since recently I > started spending time in guessing which editor I'm currently looking at, > when the editor stack doesn't have focus (see attached screenshot). > Similar for the bottom stack: where do I have to click to close the history > view? > > Feels like a regression to me. > > Seen in I20151222-0800 running on Kubuntu 15.10 with SWT_GTK3=0. > > Since in this bug we are discussing how to de-emphasize inactive parts, I'd > like to suggest to mark the visible editor / view by a stronger outline > around the tab, rather than continued fiddling with tab colors. The GTK2 theme you are using seem to be not usual nor the default one (both widget shapes and colors). Can you please try to set the default one (not sure which is this for Kubuntu, if it is still Oxygen then better not use it at all), but I would try Adwaita (default for Gnome) or Clearlooks-Phoenix. Another option is to try to manually configure theme colors in KDE and apply this to GTK theme in the GTK+ appearance settings tab. (In reply to Andrey Loskutov from comment #76) > The GTK2 theme you are using seem to be not usual nor the default one (both > widget shapes and colors). Can you please try to set the default one (not > sure which is this for Kubuntu, if it is still Oxygen then better not use it > at all), but I would try Adwaita (default for Gnome) or Clearlooks-Phoenix. > Another option is to try to manually configure theme colors in KDE and apply > this to GTK theme in the GTK+ appearance settings tab. In a stock Kubuntu 15.10, I have two "acceptable" themes: "Orion" (GTK2/3) and "Emacs" (GTK3 only). When taking the above snapshot "Orion" was selected for GTK2, but it seems that setting wasn't taking effect, defaulting to "Raleigh" - which would explain some of the ugliness :) (I'm well aware of the dangers of using oxygen-gtk ...). However, independent of the GTK theme (even when using oxygen-gtk or Raleigh), the colors for shown/hidden tabs was the same almost identical pair of shades of gray. Are all these themes "broken"??? How do you distinguish tabs in an inactive part in other linux environments? FWIW: - GTK2 is 2.24.28-1ubuntu1 - GTK3 is 3.16.7-0ubuntu3 (In reply to Stephan Herrmann from comment #77) < How do you > distinguish tabs in an inactive part in other linux environments? Attachment 258219 [details] shows how it looks like on GTK3 with a recent Fedora (I believe the same thing applies to all gnome3-based environments). Some other contributors have reported on the mailing-list their satisfaction regarding this theme change on Linux. Like Andrey, I'm wondering whether what you're looking at is actually the default Eclipse IDE theme. The screenshot I linked to isn't totally accurate. On a second look, I agree with Stephan that "active no focus" tabs have a color that's very close to "inactive no focus" ones, sometimes making it a bit tricky to identify which one is enabled. Maybe the "active no focus" color could be a bit brighter or outline a but stronger could be worth trying. Still a bad bug that we should address. *** Bug 497586 has been marked as a duplicate of this bug. *** If it's too hard to agree upon a set of colors that clearly conveys the different levels of activeness (6 years not being enough time to discuss this), then a solution a la bug 497586 could help very much, IMHO. (In reply to Stephan Herrmann from comment #82) > If it's too hard to agree upon a set of colors that clearly conveys the > different levels of activeness (6 years not being enough time to discuss > this), then a solution a la bug 497586 could help very much, IMHO. +1 (In reply to Stephan Herrmann from comment #82) > If it's too hard to agree upon a set of colors that clearly conveys the > different levels of activeness (6 years not being enough time to discuss > this), then a solution a la bug 497586 could help very much, IMHO. A solution a la bug 497586 just adds a new possible way of doing things, I don't think it's going to make agreement any better. Things on Linux have much improved in the last year. All it's missing is changing the grayscale of the active unselected tab. You can pick one in the Colors & Fonts preference page, it's "Inactive, unselected part color". Once you find a grayscale that looks nice to you, please share it with a screenshot and we could easily update the CSS accordingly (or you could also push a patch directly). For Windows, a similar solution could be taken. It just requires a Windows user to drive this effort and make some proposals and so far, no-one stood up. I believe fixing bug 497586 won't increase chances for a Windows user to take action here. Would there be any objection to move the Windows theme to flat UI and blue-scale (like the Linux one but using shades of blue rather than shades of grey). As I'm reading a french forum discussion about IDE, I really have the impression that no-one likes the Windows theme as it and that it should be improved with high priority. (In reply to Mickael Istria from comment #85) > Would there be any objection to move the Windows theme to flat UI and > blue-scale (like the Linux one but using shades of blue rather than shades > of grey). +1 for flat UI. This is a very common styling these days. New Gerrit change created: https://git.eclipse.org/r/94035 Created attachment 267520 [details] win patch preview > New Gerrit change created: https://git.eclipse.org/r/94035 See attached screenshot. (In reply to Mickael Istria from comment #88) > Created attachment 267520 [details] > win patch preview > > > New Gerrit change created: https://git.eclipse.org/r/94035 > > See attached screenshot. +1 way nicer IMHO The Flat theme is nicer. we could make the editor area tabs consistent with other tabs by styling the active editor tab with a light color and the inactive editor tabs with a darker color. (In reply to Patrik Suzzi from comment #90) > we could make the editor area tabs consistent with other tabs by styling the > active editor tab with a light color and the inactive editor tabs with a > darker color. There's a small difference in the color already. As your suggestion doesn't seem to be a blocker, As this issue is already 7 years old, I'd rather have it tracked in a next iteration after this change is merged. That will probably be more efficient than we've been in the last 7 years of discussion ;) (In reply to Mickael Istria from comment #91) > There's a small difference in the color already. > As your suggestion doesn't seem to be a blocker, As this issue is already 7 > years old, I'd rather have it tracked in a next iteration after this change > is merged. That will probably be more efficient than we've been in the last > 7 years of discussion ;) I agree. More enhancements could be tracked by new bugs. (In reply to Mickael Istria from comment #91) > As your suggestion doesn't seem to be a blocker, As this issue is already 7 > years old, I'd rather have it tracked in a next iteration after this change > is merged. That will probably be more efficient than we've been in the last > 7 years of discussion ;) Yes, I agree. I suggest to merge it, so that we can get the feedback in the M7 test cycle if something was broken or can be improved. (In reply to Lars Vogel from comment #94) > I suggest to merge it, so that we can get the feedback in the M7 test cycle > if something was broken or can be improved. With great pleasure ;) Gerrit change https://git.eclipse.org/r/94035 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=df243b8c7e7f85821e9609692844985519a61563 Anyone using OSX wants to work on the OSX theme? Or is it OK if we simply copy the linux theme to osx? New Gerrit change created: https://git.eclipse.org/r/94231 Gerrit change https://git.eclipse.org/r/94231 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=72fc8c826e534cd6e4e445131e4affaf1221b88c Created attachment 267580 [details] Picture showing bad background (In reply to Eclipse Genie from comment #99) > Gerrit change https://git.eclipse.org/r/94231 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=72fc8c826e534cd6e4e445131e4affaf1221b88c > This reverts the previous change since it was not good, see attached picture. Please carefully test before committing such changes. Thanks! (In reply to Dani Megert from comment #100) > This reverts the previous change since it was not good, see attached > picture. Please carefully test before committing such changes. Thanks! Can you elaborate what you mean by "not good". Unfortunately, I'm not much of a Windows users and I don't know the expectations for this theme. Also, it's still subjective. I find the theme you show in the picture more usable (and thus better) than the current one regarding active parts. (In reply to Mickael Istria from comment #101) > (In reply to Dani Megert from comment #100) > > This reverts the previous change since it was not good, see attached > > picture. Please carefully test before committing such changes. Thanks! > > Can you elaborate what you mean by "not good". The issue is with the background of the parts: it should be white (to be more precise: the same) for all of them, including the editor area. Using the background of a part to mark it active/inactive is too intrusive. Note if it was really the intention to use the background, it was not working properly: it makes no sense that the two inactive views (Problems and Outline view) have a different background. When making the Outline view active the background also becomes white again. (In reply to Dani Megert from comment #102) > The issue is with the background of the parts: it should be white (to be > more precise: the same) for all of them, including the editor area. Using > the background of a part to mark it active/inactive is too intrusive. > > Note if it was really the intention to use the background, it was not > working properly: it makes no sense that the two inactive views (Problems > and Outline view) have a different background. When making the Outline view > active the background also becomes white again. The Problem View despite being unselected, has content so it shows it (and it partially hides the background). But the background is partially visible at the head of the view (where written "0 items"). Frankly, I think that any tentative to solve this issue by putting white everywhere will end in the same result of everything being "enlightened" then perceived as active. The constraint you set up is in my opinion contrary to any possible solution to this issue. As we're disagreeing, and as Windows user and lead, you deserve to get the final word on that over me. So I give up with any tentative to change the Windows appearance under the given constraints. But I'm pretty sad to leave it in that state where everything is so white for 80% of our users that it takes them seconds to realize what's currently enabled. Accumulating over all Windows users and all the times the look for an active view daily, it's a lot of time wasted just for the sake of having a background white everywhere... (In reply to Mickael Istria from comment #103) I think that any tentative to solve this issue by putting white > everywhere will end in the same result of everything being "enlightened" > then perceived as active. The distinction should not come over the background, because that's too noisy when switching the active part. The tab of the active part should be less white, as it was in 3.x. > As we're disagreeing, and as Windows user and lead, you deserve to get the > final word on that over me. And I filed the bug report ;-). (In reply to Dani Megert from comment #104) > (In reply to Mickael Istria from comment #103) > I think that any tentative to solve this issue by putting white > > everywhere will end in the same result of everything being "enlightened" > > then perceived as active. > > The distinction should not come over the background, because that's too > noisy when switching the active part. The tab of the active part should be > less white, as it was in 3.x. FYI, it's the pattern that's used on GTK and AFAIK it's the only OS where people sometimes say they're happy with the default theme. Created attachment 267608 [details] Hard to see active part (In reply to Mickael Istria from comment #105) > FYI, it's the pattern that's used on GTK and AFAIK it's the only OS where > people sometimes say they're happy with the default theme. On 3.x the darker / grey background was used to indicate that a part currently has no input, but we never changed the background when (de-)activating a part. Otherwise, the user can no longer match a background color to a state. In my opinion this is currently broken in the GTK theme. On GTK at least the tab color for the active part is better to distinguish via tab color. Take a look at this attached picture on Windows 7 (before I reverted the change) where the Declaration view has the focus - very hard to see that active part. On the Windows 7 and GTK machines I have access to, the part backgrounds are all white as soon as they have input, so, your "all white" criticism would also apply to the GTK theme. (In reply to Dani Megert from comment #106) > Take a look at this attached picture on Windows 7 (before I > reverted the change) where the Declaration view has the focus - very hard to > see that active part. Still way better than the current state, which is the one that caused you to open this bug 7 years ago, IMO. So, what are the plans to get a proper theme for millions of users in 4.7? Created attachment 267611 [details] Current state on Windows 7 (In reply to Mickael Istria from comment #107) > (In reply to Dani Megert from comment #106) > > Take a look at this attached picture on Windows 7 (before I > > reverted the change) where the Declaration view has the focus - very hard to > > see that active part. > > Still way better than the current state, Are you talking about Windows 7? I thought you don't have a Windows 7 machine. I don't talk about any other platform. Do you really claim that the tab (color) of the Declaration view is better recognizable as active part with the proposed change (attachment 267608 [details]) than in the current state (this attachment)? (In reply to Dani Megert from comment #108) > Are you talking about Windows 7? I thought you don't have a Windows 7 > machine. Yes, I'm using your screenshots as reference (I indeed do not test on Windows 7) > Do you really claim that the tab (color) of the Declaration view is better > recognizable as active part with the proposed change (attachment 267608 [details] > [details]) than in the current state (this attachment)? But compared to the current state (your last screenshot), the active stack is IMO clearly easier to identify, and once on this stack, the active tab is relatively easy to find (although other ones could be made darker). Overall, if I look at both screenshot, the proposal helps me to reach the active stack much faster and the active part of that stack a bit slower. So, I perceive it as an improvement. (In reply to Mickael Istria from comment #109) > But compared to the current state (your last screenshot), the active stack > is IMO clearly easier to identify, and once on this stack, the active tab is > relatively easy to find (although other ones could be made darker). > Overall, if I look at both screenshot, the proposal helps me to reach the > active stack much faster and the active part of that stack a bit slower. So, > I perceive it as an improvement. Entirely not true for my perception. In the current situation I can at least search for the white tab and it is much easier to find in the current than in the proposed solution. Still not really good enough though. The same is true for the GTK theme (I mean there it is somewhat OK like in the current state on Windows 7). The key failure in Windows 7, is that inactive parts in a stack and outside a stack do not have the same tab color, and I think this is fixed in the GTK theme (on my GTK machine the active part tab is white and the inactive one gray). Currently we have 3 colors on Windows 7 (with and without the change) which is confusing. This is not the case in 3.x (please take a look). There we have only one dedicated tab color for the active part and one color for the inactive ones. (In reply to Dani Megert from comment #106) > On 3.x the darker / grey background was used to indicate that a part > currently has no input, but we never changed the background when > (de-)activating a part. Otherwise, the user can no longer match a background > color to a state.$ Filed bug 514649 to track that. Is there anyone using Windows actually planning to improve the theme for 4.7? (In reply to Mickael Istria from comment #112) > Is there anyone using Windows actually planning to improve the theme for 4.7? I'd prefer we look at this early Oxygen (4.8), because any change to the LAF can impact some users depending on the OS theme. (In reply to Dani Megert from comment #113) > (In reply to Mickael Istria from comment #112) > > Is there anyone using Windows actually planning to improve the theme for 4.7? > > I'd prefer we look at this early Oxygen (4.8), because any change to the LAF > can impact some users depending on the OS theme. +1 This is still the first visible issue in Eclipse Platform UX. Removing target as we can't find consensual contribution for win32 and osx. If someone feels motivated and able to fix it for 4.8, please assign and set the target version. Good comment from Dani on the mailing-list:
> If the changes are more radical, then we should keep the existing theme and add a new one. Maybe rename the existing theme.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |