Community
Participate
Working Groups
Similar to Bug 563496 but for the light theme.
Also see Bug 563282 as it's somewhat related :)
New Gerrit change created: https://git.eclipse.org/r/165280
Created attachment 283372 [details] Screenshot - Linux
WDYT?
I recently try a very good theme from Pierre-Yves' Planet Theme: https://raw.githubusercontent.com/PyvesB/eclipse-planet-themes/master/images/moon.png I see it has a very smart usage of selection highlight: * the current tab of the current stack has the highlight color as background * the active tabs of unactive stacks have the highight color as "overline" (but underling would probably work as well * all other tabs use the same background color. This is very nice as it allows to very easily identify the active tabs and the active stacks, and allows to get rid of several colors: the various levels of selection are using the same color, and only backgroud or overline make the difference. The amount of colors being reduced makes the theme, and the application, feel much lighter. As a bonus, the theme also gets rid of the "boxes" around the stacks, making them using the same color as the workbench background. Removing the lines and removing some more colors also make the theme much lighter. I think the default Platform theme should mimic that, but just stick closer to the "system default" palette it's using, not changing colors but getting rid of some of them.
(In reply to Mickael Istria from comment #5) > I recently try a very good theme from Pierre-Yves' Planet Theme: > https://raw.githubusercontent.com/PyvesB/eclipse-planet-themes/master/images/ > moon.png > > I see it has a very smart usage of selection highlight: > * the current tab of the current stack has the highlight color as background > * the active tabs of unactive stacks have the highight color as "overline" > (but underling would probably work as well > * all other tabs use the same background color. > > This is very nice as it allows to very easily identify the active tabs and > the active stacks, and allows to get rid of several colors: the various > levels of selection are using the same color, and only backgroud or overline > make the difference. The amount of colors being reduced makes the theme, and > the application, feel much lighter. > As a bonus, the theme also gets rid of the "boxes" around the stacks, making > them using the same color as the workbench background. Removing the lines > and removing some more colors also make the theme much lighter. > > I think the default Platform theme should mimic that, but just stick closer > to the "system default" palette it's using, not changing colors but getting > rid of some of them. Pierre-Yves, can you provide a Gerrit for platform?
@Mickael +1 for integrating elements/concepts from Pierre-Yves Moon theme into the platform theme :)
Thanks for the feedback and thoughts on the Planet themes, Mickael! (In reply to Lars Vogel from comment #6) > Pierre-Yves, can you provide a Gerrit for platform? I've put a lot of effort in my own custom themes in recent weeks and still have a lot to do; my head is exploding with CSS and stylesheets at the moment, so I'll give it a miss. :) I would recommend proceeding with great care to whoever picks this up: * there are several ongoing changes making use of the selection highlighter (the "overline") in different ways for the default light themes, for example bug 564884 or bug 563282 which both have open Gerrits. There needs to be some consensus and direction, everyone will end up stepping on each other's toes otherwise. * there's a whole preference section which configures tab appearance in General -> Appearance -> Colors and Fonts -> View and Editor Folders. You could either: 1) re-define the CSS colours in such a way that you end up with the desired look. I tried doing that for my Planet themes initially, and never managed to get things right, so I ended up not using them at all. Whilst it's okay for a custom theme to be opinionated and ignore some preference settings, it's not okay for Platform. 2) get rid of all those preferences. Some of them are already partly broken today (see bug 559312), others make little sense if you adopt uniform tabs like in Planet themes. However, that's less user customisation (and that same bug 59312 indicates that some users do care) and will require to rewrite the Dark theme at the same time. * there's work to do in CTabRendering to make things work properly with round tabs (the bottom border of the CTabFolder does not render correctly with round tabs). Again I've been opinionated in my custom themes, but recent debates in Platform show that it's probably not okay to simply drop round tabs support.
Ok, so should be go in this bug with the simple enablement of the active tab selection and open new bugs to apply more of the change Mickael likes?
(In reply to Lars Vogel from comment #9) > Ok, so should be go in this bug with the simple enablement of the active tab > selection and open new bugs to apply more of the change Mickael likes? I'm on it and will submit a patch shortly. I'm just wondering whether the theme can reference the system colors?
(In reply to Mickael Istria from comment #10) > I'm just wondering whether the theme can reference the system colors? No idea. Amit do you know?
(In reply to Mickael Istria from comment #10) > (In reply to Lars Vogel from comment #9) > > Ok, so should be go in this bug with the simple enablement of the active tab > > selection and open new bugs to apply more of the change Mickael likes? > > I'm on it and will submit a patch shortly. > I'm just wondering whether the theme can reference the system colors? (In reply to Lars Vogel from comment #11) > (In reply to Mickael Istria from comment #10) > > > I'm just wondering whether the theme can reference the system colors? > > No idea. Amit do you know? See Bug 563282 which I referenced in my above message, Philippe is precisely trying to reference the system's accent color for the highlighter. ;)
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166877
Created attachment 283707 [details] Proposal with https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166877 > https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166877 Here is a screenshot of what my proposal looks like: way less colors, very flat, mimimalist, uses highlights, easy to spot various selections... I think it's the simplest solution to achieve the usability goals and fits the current trends.
Created attachment 283708 [details] Toolbar broken
(In reply to Mickael Istria from comment #14) > Created attachment 283707 [details] > Proposal with > https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166877 > > > https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166877 > > Here is a screenshot of what my proposal looks like: way less colors, very > flat, mimimalist, uses highlights, easy to spot various selections... I > think it's the simplest solution to achieve the usability goals and fits the > current trends. I personally find the blue border around the active part distracting / annoying. Also not a big fan of the blue background of the active tab but I would live with that if others likes it. Also the patch seem to be buggy wrt. the view toolbar, see screenshot.
(In reply to Lars Vogel from comment #16) > I personally find the blue border around the active part distracting / > annoying. Also not a big fan of the blue background of the active tab but I > would live with that if others likes it. What would you suggest instead? > Also the patch seem to be buggy wrt. the view toolbar, see screenshot. Shouldn't those toolbars just inherit parent color? I'm actually not convinced it's a theme thing, but more a bug in the code of view toolbars here.
(In reply to Lars Vogel from comment #16) > I personally find the blue border around the active part distracting / > annoying. Also not a big fan of the blue background of the active tab but I > would live with that if others likes it. FWIW, I don't really care about the actual color, what I think is important is that the highlight color for active/unselected be the same as the background color for active/selected. Also, I think we can just get rid of the keyline, if the current renders permit it...
> Also the patch seem to be buggy wrt. the view toolbar, see screenshot. Fixed with new patchset.
(In reply to Lars Vogel from comment #11) > (In reply to Mickael Istria from comment #10) > > > I'm just wondering whether the theme can reference the system colors? > > No idea. Amit do you know? Sorry, I have no idea. I haven't seen any such usages in any of the eclipse theme css. So may be not. IMO, system colors should be exposed through ColorDefinitions. Themes should use ColorDefinitions only instead of hard coding colors to make themes easy to maintain.
I plan to merge https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/165280/ as a first step to enable this for the light theme. Other enhancements as suggested by Mickael could go into their own bug. https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/165280/ has been adjusted based on Mickaels Gerrit to move the color to the preferences so that the user can change it.
I personally think that adding selection highlighter (ie making the theme a heavier) per se without using it as an opportunity to improve the theme overall is not a good idea.
(In reply to Mickael Istria from comment #22) > I personally think that adding selection highlighter (ie making the theme a > heavier) per se without using it as an opportunity to improve the theme > overall is not a good idea. Please create a new bug for reducing the number of colors used, overloading a focused bug with more requirements usually leads to deadlock, i.e. no changes at all.
(In reply to Lars Vogel from comment #23) > (In reply to Mickael Istria from comment #22) > > I personally think that adding selection highlighter (ie making the theme a > > heavier) per se without using it as an opportunity to improve the theme > > overall is not a good idea. > > Please create a new bug for reducing the number of colors used, overloading > a focused bug with more requirements usually leads to deadlock, i.e. no > changes at all. I'm indeed advocating for no change at all instead of just adding highlight.
(In reply to Mickael Istria from comment #24) > I'm indeed advocating for no change at all instead of just adding highlight. Please open the bug for the reduction of colors and mark this one to depend on it.
(In reply to Lars Vogel from comment #25) > Please open the bug for the reduction of colors and mark this one to depend > on it. Or we retitle this one to "Improve current theme taking by leveraging highlight" as the coupling between using highlight and reducing the palette is very strong if we want to ensure what we ship is an enhancement over current state.
(In reply to Mickael Istria from comment #26) > (In reply to Lars Vogel from comment #25) > > Please open the bug for the reduction of colors and mark this one to depend > > on it. > > Or we retitle this one to "Improve current theme taking by leveraging > highlight" as the coupling between using highlight and reducing the palette > is very strong if we want to ensure what we ship is an enhancement over > current state. +1
(In reply to Amit Mendapara from comment #20) > (In reply to Lars Vogel from comment #11) > > (In reply to Mickael Istria from comment #10) > > > > > I'm just wondering whether the theme can reference the system colors? > > > > No idea. Amit do you know? > > Sorry, I have no idea. I haven't seen any such usages in any of the eclipse > theme css. So may be not. > > IMO, system colors should be exposed through ColorDefinitions. Themes should > use ColorDefinitions only instead of hard coding colors to make themes easy > to maintain. Hi, SWT.COLOR_* constants can be referenced through css theme thanks to class CSSSWTColorHelper: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.e4.ui.css.swt/src/org/eclipse/e4/ui/css/swt/helpers/CSSSWTColorHelper.java?id=8fab17122c0d0e9d0181ef533f0f5d4b56d31092#n96 For instance, with 563282 it defines a SWT.COLOR_SYSTEM_ACCENT, we can use COLOR-SYSTEM-ACCENT as color constant in css themes to retrieve the default system accent color.
(In reply to Philippe Dul from comment #28) > (In reply to Amit Mendapara from comment #20) > > > (In reply to Lars Vogel from comment #11) > > > > (In reply to Mickael Istria from comment #10) > > > > > > > > > I'm just wondering whether the theme can reference the system colors? > > > > > > > > No idea. Amit do you know? > > > > > > Sorry, I have no idea. I haven't seen any such usages in any of the eclipse > > > theme css. So may be not. > > > > > > IMO, system colors should be exposed through ColorDefinitions. Themes should > > > use ColorDefinitions only instead of hard coding colors to make themes easy > > > to maintain. > > > > Hi, > > SWT.COLOR_* constants can be referenced through css theme thanks to class > CSSSWTColorHelper: > https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org. > eclipse.e4.ui.css.swt/src/org/eclipse/e4/ui/css/swt/helpers/ > CSSSWTColorHelper.java?id=8fab17122c0d0e9d0181ef533f0f5d4b56d31092#n96 > > For instance, with 563282 it defines a SWT.COLOR_SYSTEM_ACCENT, we can use > COLOR-SYSTEM-ACCENT as color constant in css themes to retrieve the default > system accent color. That's really cool. I didn't know about that. I will give it a try soon.
(In reply to Amit Mendapara from comment #29) > That's really cool. I didn't know about that. I will give it a try soon. There is a current limitation that makes that system color reference don't work in ColorDefinition elements, but this is being covered by bug 565775 and should hopefully be fixed soon. I agree that referencing system colors is a major capability that's probably under-used! Thanks to that, it's possible to write a theme using a palette made mostly of system colors, thus we could design a single Eclipse theme portable across mulitple OSs and OS themes, and that would integrate well into any target by relying on system colors instead of opinionated ones hardcoded in Eclipse themes (as it is currently).
(In reply to Mickael Istria from comment #30) > I agree that referencing system colors is a major capability that's probably > under-used! Thanks to that, it's possible to write a theme using a palette > made mostly of system colors, thus we could design a single Eclipse theme > portable across mulitple OSs and OS themes, and that would integrate well > into any target by relying on system colors instead of opinionated ones > hardcoded in Eclipse themes (as it is currently). This is indeed very interesting, I think experimentation should go into this (I might give it a try sometime) :)
I think bug 565867 is a blocker for best results of a theme that would leverage highlights.
Created attachment 283807 [details] toolbar-blue.gif (In reply to Mickael Istria from comment #19) > > Also the patch seem to be buggy wrt. the view toolbar, see screenshot. > > Fixed with new patchset. When the toolbar is below the tab, should not the toolbar be gray like other toolbar ? (toolbar-blue.gif) When the toolbar is aside the tab item, its gray, but when the toolbar is below, its look really blue.
Looks like bug 564884 is a duplicate of this newer one.
(In reply to Philippe Dul from comment #33) > Created attachment 283807 [details] > toolbar-blue.gif > > (In reply to Mickael Istria from comment #19) > > > Also the patch seem to be buggy wrt. the view toolbar, see screenshot. > > > > Fixed with new patchset. > > When the toolbar is below the tab, should not the toolbar be gray like other > toolbar ? (toolbar-blue.gif) > When the toolbar is aside the tab item, its gray, but when the toolbar is > below, its look really blue. That's a good idea. However, changing that would also change the current state (for the better IMO), so can you please open a dedicated bug and link it here?
(In reply to Mickael Istria from comment #35) > > When the toolbar is below the tab, should not the toolbar be gray like other > > toolbar ? (toolbar-blue.gif) > > When the toolbar is aside the tab item, its gray, but when the toolbar is > > below, its look really blue. > > That's a good idea. However, changing that would also change the current > state (for the better IMO), so can you please open a dedicated bug and link > it here? I opened bug 565951
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/167494
I see a lot of interesting work going on here, however I am under the impression that these changes won't make it for 4.17. If that is right, could at least Bug 564884 be fixed by simply changing the color of non-active selected tabs in windows (similar to the Linux theme)? So that the user experience regression in 2.16 is resoved again.
(In reply to Rolf Theunissen from comment #38) > I see a lot of interesting work going on here, however I am under the > impression that these changes won't make it for 4.17. I'll try to merge some more interesting patches for M3 today, including a new theme proposal. > If that is right, > could at least Bug 564884 be fixed by simply changing the color of > non-active selected tabs in windows (similar to the Linux theme)? So that > the user experience regression in 2.16 is resoved again. Probably. I personally won't try to improve the current theme incrementally, my focus is more in redesigning a simpler theme thanks to highlight and closer from what other OS/editors/IDEs do nowadays.
As mentioned in last comment, I don't think the Light or Dark themes are easily fixable due to usage of hardcoded colors everywhere and other complexities that may be perceived as important for some. I also think that an approach consisting in incrementally improving the Light/Dark themes and trying to get a consensus for each incremental change is not the most efficient way to make progress. I plan to merge the new "system" theme soon as 4.18 stream is open. This theme is based on highlight and system colors, adapts very well to OS theme change (after a restart). That "System" theme will be opt-in and discussed. Then, If there is some good agreement that this theme is to be preferred in most cases over the current light/dark ones; we can consider making it the default one.
Created attachment 283921 [details] Proposal with https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166877 New proposal with updated https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166877 . Same Eclipse "System" theme on 4 different GTK themes.
I just gave it a try. A good start in right direction. We may also need a way to detect dark system theme and apply editor theme accordingly. +1
(In reply to Amit Mendapara from comment #42) > We may also need a way to detect dark system theme and apply editor theme > accordingly. We could also/instead tweak the default preferences in text editor (the ones that do not refer to system values at least) to derive the value according to other system colors and find defaults that would work decently in any theme, without having to customize them explicitly. For example, we could define the selected line highlight background as 50% of background color + 50% of selection color and so on.
IMO, editor color themes should use fixed colors, two schemes should be provided, a light and dark variant. Also, the eclipse should provide a way to choose editor color scheme besides the UI theme.
(In reply to Amit Mendapara from comment #44) > IMO, editor color themes should use fixed colors, two schemes should be > provided, a light and dark variant. Also, the eclipse should provide a way > to choose editor color scheme besides the UI theme. Is dark and light enough to cover all existing themes? Ie if I have a OS or workbench theme which is full of red, what variant should be used? light or dark? I'm afraid binary choices are too restraining. For sure, it would be great if Eclipse IDE would allow editor themes (and it somehow does with plugins like TM4E or eclipse-color-themes), but the difficulty becomes how to decide of an editor theme according to the workbench theme? We could just compute which themes is "most-compatible" with the editor background (which is from the system). All that seem to highlight that editor customization is not trivial. Shouldn't we bring this discussion to some other more focused bug?
CSS styling allows to set preferences, you so could use the system colors to configure the view and editor color preferences.
(In reply to Lars Vogel from comment #46) > CSS styling allows to set preferences, you so could use the system colors to > configure the view and editor color preferences. It's not as easy as you seem to think ;) Preferences are hardcoded key/value pairs, wrapped in a string. They don't seem to support CSS syntax, are parsed as plain strings without substitution by the CSS engine and don't seem really open to consumption of ColorDefinitions nor transformation of ColorDefinition symbols to rgb, and as far as I know support the CSS engine doesn't have any support for "color arithmetic" allowing the theme to derive a color from other ones. So while all that can probably be implemented, it's not something we can use right now.
(In reply to Mickael Istria from comment #47) > (In reply to Lars Vogel from comment #46) > > CSS styling allows to set preferences, you so could use the system colors to > > configure the view and editor color preferences. > > It's not as easy as you seem to think ;) Preferences are hardcoded key/value > pairs, wrapped in a string. They don't seem to support CSS syntax, are > parsed as plain strings without substitution by the CSS engine and don't > seem really open to consumption of ColorDefinitions nor transformation of > ColorDefinition symbols to rgb, and as far as I know support the CSS engine > doesn't have any support for "color arithmetic" allowing the theme to derive > a color from other ones. > So while all that can probably be implemented, it's not something we can use > right now. Sounds like we should implement implement some dynamic color parsing in the preference CSS handler. Please open a new bug for that.
(In reply to Mickael Istria from comment #45) > (In reply to Amit Mendapara from comment #44) > > IMO, editor color themes should use fixed colors, two schemes should be > > provided, a light and dark variant. Also, the eclipse should provide a way > > to choose editor color scheme besides the UI theme. > > Is dark and light enough to cover all existing themes? Ie if I have a OS or > workbench theme which is full of red, what variant should be used? light or > dark? > I'm afraid binary choices are too restraining. For sure, it would be great > if Eclipse IDE would allow editor themes (and it somehow does with plugins > like TM4E or eclipse-color-themes), but the difficulty becomes how to decide > of an editor theme according to the workbench theme? We could just compute > which themes is "most-compatible" with the editor background (which is from > the system). > All that seem to highlight that editor customization is not trivial. > Shouldn't we bring this discussion to some other more focused bug? IMO, yes we should think about only two system themes, light and dark. All the 3 main operating systems now a days have two modes and we should support those two system themes only.
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/168845
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166877 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4b65c85353a056ad4150c740f0f669b07f9a436c
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/168845 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=4b694cfbe89f82e7d5ebad5ca5dbb80a359b6f0c
(In reply to Eclipse Genie from comment #52) > Gerrit change > https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/168845 was merged > to [master]. > Commit: > http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=4b694cfbe89f82e7d5ebad5ca5dbb80a359b6f0c The images look blurred in https://www.eclipse.org/eclipse/news/4.18/platform.php#system-theme. These can be improved with the allowed 800 pixels width or by cropping them to leave out some parts.
*** Bug 340889 has been marked as a duplicate of this bug. ***
