Community
Participate
Working Groups
Created attachment 272964 [details] Screenshot Looking at all the great dark news in https://www.eclipse.org/eclipse/news/4.8/M6/ made me realize that the expand node should also get adjusted. See screenshot for what I mean, not sure if it is called the expand button.
Created attachment 272977 [details] collapse icon with transparency Removing the background is not an option as the user won't be able to see the dark "+" or "-" sign. I experimented with giving the background some transparency. In the screenshot I did only adapt the "collapse" icons. The "expand" is still unchanged.
Created attachment 272978 [details] collapse icon with transparency in ligth theme
(In reply to Lars Vogel from comment #0) > Created attachment 272964 [details] > Screenshot > > Looking at all the great dark news in > https://www.eclipse.org/eclipse/news/4.8/M6/ made me realize that the expand > node should also get adjusted. > > See screenshot for what I mean, not sure if it is called the expand button. In your screenshot u see that the "expanded" (the one with the "-" sign) is much greyer colors. I find this a bit strange. Do you know of any good reasons why the two icons don't use the same colors?
(In reply to Matthias Becker from comment #1) > Created attachment 272977 [details] > collapse icon with transparency > > Removing the background is not an option as the user won't be able to see > the dark "+" or "-" sign. > I experimented with giving the background some transparency. > > In the screenshot I did only adapt the "collapse" icons. The "expand" is > still unchanged. the adapted icon is the one with the "+" sign in it.
> Do you know of any good reasons why the two icons don't use the same colors? No > the adapted icon is the one with the "+" sign in it. Looks way better to me. Till as JDT UI committer can you have a look?
(In reply to Matthias Becker from comment #3) > In your screenshot u see that the "expanded" (the one with the "-" sign) is > much greyer colors. I find this a bit strange. Do you know of any good > reasons why the two icons don't use the same colors? Maybe to make it easier to distinguish the state? They are quite small after all. You could try to find the bug where they were added, maybe there is some discussion.
(In reply to Till Brychcy from comment #6) > (In reply to Matthias Becker from comment #3) > > In your screenshot u see that the "expanded" (the one with the "-" sign) is > > much greyer colors. I find this a bit strange. Do you know of any good > > reasons why the two icons don't use the same colors? > > Maybe to make it easier to distinguish the state? They are quite small after > all. > You could try to find the bug where they were added, maybe there is some > discussion. Or we just make look similar. I don't see the value to have the different these days. Inconsistencies are annoying.
(In reply to Lars Vogel from comment #7) > (In reply to Till Brychcy from comment #6) > > (In reply to Matthias Becker from comment #3) > > > In your screenshot u see that the "expanded" (the one with the "-" sign) is > > > much greyer colors. I find this a bit strange. Do you know of any good > > > reasons why the two icons don't use the same colors? > > > > Maybe to make it easier to distinguish the state? They are quite small after > > all. > > You could try to find the bug where they were added, maybe there is some > > discussion. > > Or we just make look similar. I don't see the value to have the different > these days. Inconsistencies are annoying. Sorry, I don't understand the "these days" reference. This is not a fashion thing, but a usability thing. And I agree that inconsistencies are annoying, but this is definitely not an inconsistency but a well thought-out design. I've have now tried it in an actual editor. The button of a folded region looks active, while the not folded region's icon looks a bit in the background. The difference is more noticable in the light design. This has two effects: 1) the difference can be noted without focussing the icon. In effect, you don't have to think about it and somehow now that there is a folded region. 2) the "not folded" icons don't distract as much from other ruler items.
Till, If we still like something today we should keep it, but looking in the Git history (given the really bad commit messages in the past) should not limit our ability to improve icons. So let's find good icons. To be honest I don't have super strong opinions about icons, exapt that they should not looks bad in both the light and the dark theme. Example for GC icons which look super bad IMHO are View menu, Minimize and Maximize. So I don't have the high opinion about the past design process which resulted in these icons.
(In reply to Lars Vogel from comment #9) > Till, If we still like something today we should keep it, but looking in the > Git history (given the really bad commit messages in the past) should not > limit our ability to improve icons. Hmmm, the whole discussion started because something about the existing icons wasn't understood, which is bad, if we want to improve it. Looking in the history often helps (not as much the git commits, but the discussions in bugzilla). But in this case, unfortunately not: The seem to be from commit 7664bd3ce4d37206dda2bcd22f49cb09ac192779 with the comment "new projection annotation presentation", so no bugzilla referenced. > > So let's find good icons. To be honest I don't have super strong opinions > about icons, exapt that they should not looks bad in both the light and the > dark theme. +1 to that
Created attachment 272995 [details] Old (left) and new (right) in comparison in dark theme
New Gerrit change created: https://git.eclipse.org/r/118640
New Gerrit change created: https://git.eclipse.org/r/118641
Created attachment 272996 [details] Old (left) and new (right) in comparison in light theme
I'm in vacation so I cannot test the changes but +1 for them based on the screenshot. AFAIK it is still ok to commit them today for M6 as they are not "big" patches.
(In reply to Till Brychcy from comment #8) > And I agree that inconsistencies are annoying, but this is definitely not an > inconsistency but a well thought-out design. > > I've have now tried it in an actual editor. The button of a folded region > looks active, while the not folded region's icon looks a bit in the > background. The difference is more noticable in the light design. > > This has two effects: > 1) the difference can be noted without focussing the icon. In effect, you > don't have to think about it and somehow now that there is a folded region. > 2) the "not folded" icons don't distract as much from other ruler items. See the attachments that I just uploaded. I added some tranparency to the background so that the icons are not that bright in the dark theme (but almost stay the same in the light theme). For the "expanded" icon is made the "-" a bit darker than it has been before so that is has more contrast to the changed background but still is more faded than the "+" sign in the "collapsed" icon. What do you think Lars and Till?
I think the (-) button needs more work. (On the actual screen this is much smaller than in the screen shots) The minus itself is still hard to see (maybe because of the blueish background) and there seem to be some too-bright pixels to left and to the right of it. Maybe the whole border of the button could be made a bit darker? There no need to rush this, we shouldn't release anything that is just different, but not really an improvement. Technical question: Would it be possible to specify design specific icon-names via css?
(In reply to Till Brychcy from comment #17) > I think the (-) button needs more work. > > (On the actual screen this is much smaller than in the screen shots) > I did not change the size of any object in the icon. > The minus itself is still hard to see (maybe because of the blueish > background) and there seem to be some too-bright pixels to left and to the > right of it. Maybe the whole border of the button could be made a bit darker? But not as dark as in the "+"-version of the icon? > > There no need to rush this, we shouldn't release anything that is just > different, but not really an improvement. Sure > > Technical question: Would it be possible to specify design specific > icon-names via css? Not that I am aware of. That would really be a good thing to have because one no longer needs to dark icons that look good both on light and dark background.
(In reply to Matthias Becker from comment #18) > (In reply to Till Brychcy from comment #17) > > I think the (-) button needs more work. > > > > (On the actual screen this is much smaller than in the screen shots) > > > I did not change the size of any object in the icon. This is not what i meant. At least on my browser (chromse) these high-res screenshots are show twice as big in each direction as if they are in the actual eclipse window.
Created attachment 273002 [details] Old (left) vs. Next version of the improved icon (right) Till, what do you think about this version? I made the "-" sign a bit darker. I degreased the saturation of the blue-ish background so it looks a bit more grey. I also made the border (the circle) a little bit darker (but only in the "-" version of the icon.
(In reply to Matthias Becker from comment #20) > Created attachment 273002 [details] > Old (left) vs. Next version of the improved icon (right) > > Till, what do you think about this version? > I made the "-" sign a bit darker. I degreased the saturation of the blue-ish > background so it looks a bit more grey. I also made the border (the circle) > a little bit darker (but only in the "-" version of the icon. The "-" can be recognised now, but the icon stills looks like it is "dirty" in the dark design. Maybe we can add icons that are optimised for the dark case and add a check in java if the background colour's luma is less than < 0.5 (see Control#luma in the swt cocoa port) and use the dark-optimised icons in this case.
Currently it is not possible to change the icons via CSS, so we should first try to optimize the existing icons for both themes.
(In reply to Lars Vogel from comment #22) > Currently it is not possible to change the icons via CSS, so we should first > try to optimize the existing icons for both themes. And the correct solution is to use the existing CSS engine to replace icons and not to build another extra solution.
(In reply to Lars Vogel from comment #23) > (In reply to Lars Vogel from comment #22) > > Currently it is not possible to change the icons via CSS... So is it, or it it not? > ..., so we should first > > try to optimize the existing icons for both themes. In my opinion, I don't think we're under time pressure here, the original icons don't look that bad. Of course, if we can arrive at icons that look good and work in both design, I'm all for them. > > And the correct solution is to use the existing CSS engine to replace icons > and not to build another extra solution. Yeah, that's why I asked :-)
> Currently it is not possible to change the > icons via CSS... So is it, or it it not? Currently it is not possible to change the icons via CSS.
(In reply to Till Brychcy from comment #21) > The "-" can be recognised now, but the icon stills looks like it is > "dirty" in the dark design. I don't have this "dirty" impression. Maybe a matter of taste.
(In reply to Lars Vogel from comment #23) > And the correct solution is to use the existing CSS engine to replace icons > and not to build another extra solution. Are there any concept ideas how this can be implemented?
(In reply to Lars Vogel from comment #23) > And the correct solution is to use the existing CSS engine to replace icons > and not to build another extra solution. My must this be in the CSS? Today we already have a mechanism for locale-specific icons (via the $nl$ variable in the icon path). See https://wiki.eclipse.org/Eclipse_Globalization_Guidelines#Locale_specific_files Couldn't we build something similar where the theme-id is then encode in the icons' file path?
(In reply to Matthias Becker from comment #28) > (In reply to Lars Vogel from comment #23) > > And the correct solution is to use the existing CSS engine to replace icons > > and not to build another extra solution. > > My must this be in the CSS? > > Today we already have a mechanism for locale-specific icons (via the $nl$ > variable in the icon path). See > https://wiki.eclipse.org/Eclipse_Globalization_Guidelines#Locale_specific_files > > Couldn't we build something similar where the theme-id is then encode in the > icons' file path? -1 to combine those two things.
(In reply to Dani Megert from comment #29) > (In reply to Matthias Becker from comment #28) > > (In reply to Lars Vogel from comment #23) > > > And the correct solution is to use the existing CSS engine to replace icons > > > and not to build another extra solution. > > > > My must this be in the CSS? > > > > Today we already have a mechanism for locale-specific icons (via the $nl$ > > variable in the icon path). See > > https://wiki.eclipse.org/Eclipse_Globalization_Guidelines#Locale_specific_files > > > > Couldn't we build something similar where the theme-id is then encode in the > > icons' file path? > > -1 to combine those two things. So you propose to do it in CSS, Dani?
(In reply to Matthias Becker from comment #30) > > -1 to combine those two things. > > So you propose to do it in CSS, Dani? Either that or some new mechanism.
If we implement this via CSS I see some questions: - What is the selector for an existing icon - What is the property for the replacement icon - We must then hook something into the image creation so that when we switch the theme we can replace the existing images with the replacement icons. Any idea on that?
(In reply to Matthias Becker from comment #32) > If we implement this via CSS I see some questions: > - What is the selector for an existing icon > - What is the property for the replacement icon > - We must then hook something into the image creation so that when we switch > the theme we can replace the existing images with the replacement icons. Any > idea on that? We should move the general discussion to exchange icons via CSS (or different means) to another bug, this bug is about optimizing the existing icons for dark the light usage. I created Bug 532695 for the general discussion how to replace icons via CSS.
New icons look the same to me in the light theme and much nicer in the dark theme. So I plan to commit the new icons unless someone wants to provide ever better icons.
(In reply to Lars Vogel from comment #34) > New icons look the same to me in the light theme and much nicer in the dark > theme. So I plan to commit the new icons unless someone wants to provide > ever better icons. Till had some concerns. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=531876#c21
(In reply to Matthias Becker from comment #35) > Till had some concerns. See > https://bugs.eclipse.org/bugs/show_bug.cgi?id=531876#c21 Unfortunately currently we cannot not have different icons sets for dark and light so we need to improve icons to look good in both designs.
Gerrit change https://git.eclipse.org/r/118640 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=f0d65841e1d7ecf42e516a003be7ef9a6a99a73e
Ok, lets see how this looks in real life in the dark theme. If you see an opportunity to improve the existing icons for light and dark please reopen. @Matthias, please add to N&N
Gerrit change https://git.eclipse.org/r/118641 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.images.git/commit/?id=c2df34c13eaf113ef5361b71406ae55c397d17ae
New Gerrit change created: https://git.eclipse.org/r/120049
(In reply to Lars Vogel from comment #38) > @Matthias, please add to N&N Done. Can you please review?
Gerrit change https://git.eclipse.org/r/120049 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=778fb6d58dc5118fe2cb2ec6a5d1bb32b0733519
New Gerrit change created: https://git.eclipse.org/r/120058
Gerrit change https://git.eclipse.org/r/120058 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=f78f35673d38fd1d1bb4729cd8993b571648f70a
verified on Version: Photon (4.8) Build id: I20180507-2205
