Community
Participate
Working Groups
We would like to add support for the following usecases: Usecase 1: override font and color definitions from the CSS Currently we support the font and color definitions by the 'org.eclipse.ui.themes' extension point (the fontDefinition and colorDefinition elements) like below: <fontDefinition label="%FontsPreference.TitleFont" categoryId="org.eclipse.ui.presentation.default" id="org.eclipse.ui.workbench.TAB_TEXT_FONT"> <description> %FontsPreference.TitleFontDescription </description> </fontDefinition> It can be overridden by the user using the 'Preferences>General>Appearance>Colors and Fonts' preference page. One option for overriding this in the CSS would be to accept rules for special DOM elements that we would need to understand, for instance: FontDefinition#org-eclipse-ui-workbench-TAB_TEXT_FONT { font-size: 9; font-style: italic; } If we added extra properties, like eclipse-font-name and eclipse-font-category-id we could even allow defining new font definitions in the CSS Usecase 2: Allow CSS to be tied into existing preferences We currently have CSS definitions that look like: .MPartStack { font-size: 11; swt-simple: false; swt-mru-visible: false; } From Juno on, that has defined the Part title font size. When users update the preference, it doesn't change the size, one has to edit the CSS directly. We could add the following support for fonts and colors definitions: .MPartStack { font-family: '#org-eclipse-ui-workbench-TAB_TEXT_FONT'; font-size: default; -> we read size from specified font definition font-style: default -> we read style from specified font definition color: '#CACTIVE_HYPERLINK_COLOR' swt-simple: false; swt-mru-visible: false; }
I'd like to propose (IIRC there's already a bugzilla) to allow me to register color constants myself. I've already hacked this into the CSS engine at https://github.com/tomsontom/e4-e3theme/tree/master/at.bestsolution.e4.theme.css
(In reply to Daniel Rolka from comment #0) > We would like to add support for the following usecases: ... > If we added extra properties, like eclipse-font-name and > eclipse-font-category-id we could even allow defining new font definitions > in the CSS > I've opened another Bug 419018 for it since it looks like the extention for base requirement Daniel
Daniel, would that allow to set configure the text and font in the Java editor? This would be useful for Bug 416218.
Created attachment 236272 [details] Style sheet used during tests
Created attachment 236273 [details] Workbench styled with test stylesheet
Created attachment 236274 [details] Preference page for test stylesheet [1]
Created attachment 236275 [details] Preference page for test stylesheet [2]
Created attachment 236276 [details] Preference page for test stylesheet [3]
Created attachment 236277 [details] Preference page for test stylesheet [4]
(In reply to Thomas Schindl from comment #1) > I'd like to propose (IIRC there's already a bugzilla) to allow me to > register color constants myself. > > I've already hacked this into the CSS engine at > https://github.com/tomsontom/e4-e3theme/tree/master/at.bestsolution.e4.theme. > css Let me propose another patch for that. See the attachments to review how it works Gerrit review link: https://git.eclipse.org/r/#/c/17212/ Daniel
(In reply to Lars Vogel from comment #3) > Daniel, would that allow to set configure the text and font in the Java > editor? This would be useful for Bug 416218. Yes, however at this moment you are not able to define the new font/color definitions with CSS (I've created the separate bug 419018 for that). Using this patch you can override with CSS any font/color definition defined by the 'org.eclipse.ui.themes' extension points of contributing plugins. It is the proposal of implementation so we can process it in any direction, Daniel
Created attachment 236293 [details] java editor styled with CSS (In reply to Daniel Rolka from comment #11) > (In reply to Lars Vogel from comment #3) > > Daniel, would that allow to set configure the text and font in the Java > > editor? This would be useful for Bug 416218. > > Yes, however at this moment you are not able to define the new font/color > definitions with CSS (I've created the separate bug 419018 for that). Using > this patch you can override with CSS any font/color definition defined by > the 'org.eclipse.ui.themes' extension points of contributing plugins. > > It is the proposal of implementation so we can process it in any direction, > Daniel Snapshot with demo Daniel
It would be also useful to have a way to handle a fallback when setting a font-family property (in case the user has not installed that font on his machine). Something like it can be performed in regular CSS: font-family: 'Segoe UI', Helvetica, Arial, sans-serif; or a way to embed a local font in fontDefinition, something like: <fontDefinition label="%FontsPreference.TitleFont" categoryId="org.eclipse.ui.presentation.default" id="org.eclipse.ui.workbench.TAB_TEXT_FONT"> url=("./path/to/myfont.ttf")> </fontDefinition> would it be possible and/or makes sense?
(In reply to Andrea Guarinoni from comment #13) > It would be also useful to have a way to handle a fallback when setting a > font-family property (in case the user has not installed that font on his > machine). > > Something like it can be performed in regular CSS: > font-family: 'Segoe UI', Helvetica, Arial, sans-serif; > > or a way to embed a local font in fontDefinition, something like: > <fontDefinition > label="%FontsPreference.TitleFont" > categoryId="org.eclipse.ui.presentation.default" > id="org.eclipse.ui.workbench.TAB_TEXT_FONT"> > url=("./path/to/myfont.ttf")> > </fontDefinition> > > would it be possible and/or makes sense? The e4 CSS is not 100% compatible with the regular CSS (we support some subset of the CSS2 specification), however I think the support for the multiple font families is a good idea. Since it is not related to this bug, please open a new one if required I'm not sure about extending the fontDefinition with custom fonts. Is it really needed by the RCP applications? Daniel
ok, thanks Daniel, I think that the first possible solution would be enough. The second one should grant a total control on the look of the texts regardless of the user platform configuration but it would be a plus. Andrea
I've released https://git.eclipse.org/r/#/c/17212/ as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f99429bb1e1e016497dad9e5a86f0941a2f314ac and http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=eb5387f3b63aea06431eba5df9c0ce6614ff8687 I guess that gives us the ability to reference font definitions within the CSS. What's the next step (one of the goals is to get normal interaction between our CSS and the view title font in the Colors and Fonts preference page). PW
(In reply to Paul Webster from comment #16) > I've released https://git.eclipse.org/r/#/c/17212/ as > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=f99429bb1e1e016497dad9e5a86f0941a2f314ac and > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=eb5387f3b63aea06431eba5df9c0ce6614ff8687 > > I guess that gives us the ability to reference font definitions within the > CSS. > > What's the next step (one of the goals is to get normal interaction between > our CSS and the view title font in the Colors and Fonts preference page). > > PW I think the next step will be updating the CSS stylesheets to use the color/font definitions exposed by the Colors and Fonts preference page. Additionally when some color/font definition is updated in the preference page it will be applied to the proper widgets to reflect this change without restarting the Eclipse. I've just started to work on this part. When it is done I'm going to add the last piece of this functionality - the Bug419018 Daniel
(In reply to Paul Webster from comment #16) > I've released https://git.eclipse.org/r/#/c/17212/ as > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=f99429bb1e1e016497dad9e5a86f0941a2f314ac and I think this commit did break the changes in Bug 420035.
(In reply to Lars Vogel from comment #18) > (In reply to Paul Webster from comment #16) > > I've released https://git.eclipse.org/r/#/c/17212/ as > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > > ?id=f99429bb1e1e016497dad9e5a86f0941a2f314ac and > > I think this commit did break the changes in Bug 420035. I don't think so. I have verified it in the build I20131028-2000 that contains both changes and it works fine for me. When you want to use the SWT constants in the CSS color properties you have to replace the underscore characters with the dash ones in the constant name and skip the 'SWT.'prefix (the Bug 420035 implements it in this way) i.e. like below: .MPartStack { color: COLOR-YELLOW; } If you have some usecase where it does not work for you please let me know and I will check it, Daniel
> I don't think so. I have verified it in the build I20131028-2000 that > contains both changes and it works fine for me. When you want to use the SWT > constants in the CSS color properties you have to replace the underscore > characters with the dash ones in the constant name and skip the 'SWT.'prefix > (the Bug 420035 implements it in this way) i.e. like below: > > .MPartStack { > color: COLOR-YELLOW; > } > > If you have some usecase where it does not work for you please let me know > and I will check it, I see a difference between M2 and M2 on Linux for "COLOR-LIST-SELECTION". .DragFeedback { background-color: COLOR-LIST-SELECTION; } I added that to e4_basestyle.css via https://git.eclipse.org/r/#/c/18015/ On M2 I get under Ubuntu a nice orange and with M3 a white. [Note: SWT also changed in M3 to GTK3, not sure if that has an effect]
> I see a difference between M2 and M2 on Linux for "COLOR-LIST-SELECTION". > > .DragFeedback { > background-color: COLOR-LIST-SELECTION; > } > > I added that to e4_basestyle.css via https://git.eclipse.org/r/#/c/18015/ > > On M2 I get under Ubuntu a nice orange and with M3 a white. [Note: SWT also > changed in M3 to GTK3, not sure if that has an effect] Looks like that the different is related to GTK3. If I start M3 with GTK2, I works again correctly. I created Bug 420989 for SWT.
Is it also possible to control the font settings in the Java preferences located under Java-> Editor -> Syntax Coloring?
(In reply to Lars Vogel from comment #22) > Is it also possible to control the font settings in the Java preferences > located under Java-> Editor -> Syntax Coloring? It seems that it is a separate mechanism used by the JDT and it is not controlled by the Font and Color definitions so you are not able to override the 'syntax coloring' settings with CSS. Please open the separate bug for it and I will take a look at it later thanks, Daniel
(In reply to Daniel Rolka from comment #17) > I think the next step will be updating the CSS stylesheets to use the > color/font definitions exposed by the Colors and Fonts preference page. > Additionally when some color/font definition is updated in the preference > page it will be applied to the proper widgets to reflect this change without > restarting the Eclipse. > > I've just started to work on this part. > I've just pushed the changes to Gerrit that provide the functionality above: https://git.eclipse.org/r/#/c/18382/ and https://git.eclipse.org/r/#/c/18383/ The change 18383 is only the proposal of styling with Font and Color definitions and it definitely requires some additional tunnings thanks, Daniel
> Please open the separate bug for it and I will take a look at it later Done, thanks. https://bugs.eclipse.org/bugs/show_bug.cgi?id=422536
(In reply to Daniel Rolka from comment #24) > I've just pushed the changes to Gerrit that provide the functionality above: > https://git.eclipse.org/r/#/c/18382/ I've started working through this change. I currently get 2 errors in one of the new tests: UIAllTests-fixed org.eclipse.e4.ui.tests.UIAllTests org.eclipse.e4.ui.workbench.renderers.swt.ThemeDefinitionChangedHandlerTest testHandleEventWhenThemeChanged(org.eclipse.e4.ui.workbench.renderers.swt.ThemeDefinitionChangedHandlerTest) Wanted but not invoked: cSSEngine.reapply(); -> at org.eclipse.e4.ui.workbench.renderers.swt.ThemeDefinitionChangedHandlerTest.testHandleEventWhenThemeChanged(ThemeDefinitionChangedHandlerTest.java:65) Actually, there were zero interactions with this mock. at org.eclipse.e4.ui.workbench.renderers.swt.ThemeDefinitionChangedHandlerTest.testHandleEventWhenThemeChanged(ThemeDefinitionChangedHandlerTest.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at junit.framework.TestCase.runTest(TestCase.java:176) at junit.framework.TestCase.runBare(TestCase.java:141) at junit.framework.TestResult$1.protect(TestResult.java:122) at junit.framework.TestResult.runProtected(TestResult.java:142) at junit.framework.TestResult.run(TestResult.java:125) at junit.framework.TestCase.run(TestCase.java:129) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426) testHandleEventWhenCSSEngineNotFoundForWidget(org.eclipse.e4.ui.workbench.renderers.swt.ThemeDefinitionChangedHandlerTest) Wanted but not invoked: cSSEngine.reapply(); -> at org.eclipse.e4.ui.workbench.renderers.swt.ThemeDefinitionChangedHandlerTest.testHandleEventWhenCSSEngineNotFoundForWidget(ThemeDefinitionChangedHandlerTest.java:120) Actually, there were zero interactions with this mock. at org.eclipse.e4.ui.workbench.renderers.swt.ThemeDefinitionChangedHandlerTest.testHandleEventWhenCSSEngineNotFoundForWidget(ThemeDefinitionChangedHandlerTest.java:120) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at junit.framework.TestCase.runTest(TestCase.java:176) at junit.framework.TestCase.runBare(TestCase.java:141) at junit.framework.TestResult$1.protect(TestResult.java:122) at junit.framework.TestResult.runProtected(TestResult.java:142) at junit.framework.TestResult.run(TestResult.java:125) at junit.framework.TestCase.run(TestCase.java:129) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
(In reply to Daniel Rolka from comment #24) > I've just pushed the changes to Gerrit that provide the functionality above: > https://git.eclipse.org/r/#/c/18382/ Thanks Daniel for this patch, I think it is definitely going in the right direction. Some suggestions. - modify the IColorAndFontProvider interface to deal in actual Color and Font SWT objects. It's backed by the 3.x ITheme ColorRegistry and FontRegistry, so they're already managing the color and font resource lifecycle (which is the lifecycle of the application). - You can remove the VolatileResource pattern. It will simplify getting a resource (since there won't be any instanceof or downcasting) and we won't be disposing fonts or colors early when they might still be in use. - You can still augment the org.eclipse.e4.ui.css.swt.resources.SWTResourcesRegistry and mark Colors and Fonts that you get from the IColorAndFontProvider so you can invalidate them later (simply remove them from the SWTResourcesRegistry and they'll be reset on the various widgets by the re-apply). PW
(In reply to Paul Webster from comment #27) > (In reply to Daniel Rolka from comment #24) > > I've just pushed the changes to Gerrit that provide the functionality above: > > https://git.eclipse.org/r/#/c/18382/ > > Thanks Daniel for this patch, I think it is definitely going in the right > direction. > > Some suggestions. > > - modify the IColorAndFontProvider interface to deal in actual Color and > Font SWT objects. It's backed by the 3.x ITheme ColorRegistry and > FontRegistry, so they're already managing the color and font resource > lifecycle (which is the lifecycle of the application). > > - You can remove the VolatileResource pattern. It will simplify getting a > resource (since there won't be any instanceof or downcasting) and we won't > be disposing fonts or colors early when they might still be in use. > > - You can still augment the > org.eclipse.e4.ui.css.swt.resources.SWTResourcesRegistry and mark Colors and > Fonts that you get from the IColorAndFontProvider so you can invalidate them > later (simply remove them from the SWTResourcesRegistry and they'll be reset > on the various widgets by the re-apply). > > PW I've pushed the new version of patch to Gerrit together with my comments. Unfortunately we can not use directly the resources from the 3.x ITheme since it corrupts the style cascading (wider explanation I've put in my comments) thanks, Daniel
(In reply to Daniel Rolka from comment #28) > I've pushed the new version of patch to Gerrit together with my comments. > Unfortunately we can not use directly the resources from the 3.x ITheme > since it corrupts the style cascading (wider explanation I've put in my > comments) Thanks for the explanation. I just have 4 comments on the new patch, it looks good. PW
(In reply to Daniel Rolka from comment #24) > I've just pushed the changes to Gerrit that provide the functionality above: > https://git.eclipse.org/r/#/c/18382/ Thanks Daniel, I've released this as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9d35505dbe80ad631a62f89ff02e2f4af663976e PW
(In reply to Daniel Rolka from comment #24) > > https://git.eclipse.org/r/#/c/18383/ > I've just review this. I really like the idea of exposing the color and font bridge in the Classic CSS theme. The default 3.x color and font theme should be compatible with the Classic CSS theme. This still needs some work, though: - active tabs are not blue - no blue border around the active stack. - toolbar are a different grey color when their stack is not active. PW
Daniel, could you spin https://git.eclipse.org/r/#/c/18383/ off into its own bug: Update the classic theme to use the default color and font definitions? Then is there anything left to do here, or the main work is done and we can close this? PW
(In reply to Paul Webster from comment #32) > Daniel, could you spin https://git.eclipse.org/r/#/c/18383/ off into its own > bug: Update the classic theme to use the default color and font definitions? > > Then is there anything left to do here, or the main work is done and we can > close this? > > PW Done. The new bug for it with the new Gerrit review is Bug 423704 Daniel
Thanks Daniel. This bug can be verified with M4 PW
Created attachment 238214 [details] Stylesheet used during bug's verification Verified in the build: SDK-I20131209-2000-win32-x86_64 Daniel
