Community
Participate
Working Groups
It would be useful if it would be possible to control the system highlighting of the Java source editor (and others) via CSS. Currently you have to do this via the Java preferences located under Java-> Editor -> Syntax Coloring? Daniel suggested in https://bugs.eclipse.org/bugs/show_bug.cgi?id=419016#c23 to open a new bug for this feature request.
I think the Eclipse color theme does something similar, it is also EPL. https://github.com/eclipse-color-theme/eclipse-color-theme
Daniel, it this fix with the new font or color dialog, or is there still something missing?
(In reply to Lars Vogel from comment #2) > Daniel, it this fix with the new font or color dialog, or is there still > something missing? It is still unresolved. I think the best option would be modifying the JDT in order to use the 3.x themes. Currently it uses custom Font/Color management and stores/gets resources directly in the Preference store Daniel
(In reply to Daniel Rolka from comment #3) We could support setting preferences via CSS, e.g., Preferences { org.eclipse.core.resources/refresh.lightweight.enabled:true } This would allow to set every preference value via CSS including JDT.
(In reply to Lars Vogel from comment #4) > (In reply to Daniel Rolka from comment #3) > > We could support setting preferences via CSS, e.g., > > Preferences { > org.eclipse.core.resources/refresh.lightweight.enabled:true > } > > This would allow to set every preference value via CSS including JDT. I'm not sure if we should modify the preferences via CSS. I think the 'plugin_customization.ini' file is better option in order to do it (http://www.eclipse.org/eclipse/platform-core/documents/user_settings/plugin_customization.html) Maybe we should reassign the bug to the JDT component and next prepare the proper patch where we add the 3.x theme support for the syntax coloring Daniel
(In reply to Daniel Rolka from comment #5) > I'm not sure if we should modify the preferences via CSS. I think the > 'plugin_customization.ini' file is better option in order to do it > (http://www.eclipse.org/eclipse/platform-core/documents/user_settings/ > plugin_customization.html) The disadvantage is that plugin_customization.ini is global, e.g. the same for all themes. Also I really like that the idea that CSS allows you to tweak everything", e.g., you would be able to activate the "Heap status" with this approach. > Maybe we should reassign the bug to the JDT component and next prepare the > proper patch where we add the 3.x theme support for the syntax coloring I think it would be great if JDT switches to the font and color dialog. Can you open a new bug for JDT? I would like to use this one for the preference setting.
(In reply to Daniel Rolka from comment #5) > I'm not sure if we should modify the preferences via CSS. I think the > 'plugin_customization.ini' file is better option in order to do it > (http://www.eclipse.org/eclipse/platform-core/documents/user_settings/ > plugin_customization.html) As Lars says, this file is not related to themes and so you can't provide 2 CSS themes with different editor content via plugin_customization.ini PW
(In reply to Lars Vogel from comment #6) > (In reply to Daniel Rolka from comment #5) > > > I'm not sure if we should modify the preferences via CSS. I think the > > 'plugin_customization.ini' file is better option in order to do it > > (http://www.eclipse.org/eclipse/platform-core/documents/user_settings/ > > plugin_customization.html) > > The disadvantage is that plugin_customization.ini is global, e.g. the same > for all themes. Also I really like that the idea that CSS allows you to > tweak everything", e.g., you would be able to activate the "Heap status" > with this approach. Do you want to override all preferences by the CSS or only the GUI related ones? For the GUI preferences only I would define the proper CSS properties (similarly as we do it for the MRU support). I think we should follow the CSS standard as much as possible. > > > Maybe we should reassign the bug to the JDT component and next prepare the > > proper patch where we add the 3.x theme support for the syntax coloring > > I think it would be great if JDT switches to the font and color dialog. Can > you open a new bug for JDT? I would like to use this one for the preference > setting. I've opened the bug 430792 for it Daniel
(In reply to Daniel Rolka from comment #8) > Do you want to override all preferences by the CSS or only the GUI related > ones? > For the GUI preferences only I would define the proper CSS properties > (similarly as we do it for the MRU support). I think we should follow the > CSS standard as much as possible. I think we should allow to set all property values. Defining separate entries for all values is not feasible, for example PyDev, JDT, Android, Perl, Git have its own editors and views with properties for their elements. Paul and I discussed that on EclipseCon and he suggested we advice using this only for UI related properties but do not limited it to it. For example with this approach you could use CSS to set the default selected buttons in any view, e.g., EGit, Console, History, which I think would be very useful to users and it is UI related.
(In reply to Lars Vogel from comment #9) > (In reply to Daniel Rolka from comment #8) > > > Do you want to override all preferences by the CSS or only the GUI related > > ones? > > For the GUI preferences only I would define the proper CSS properties > > (similarly as we do it for the MRU support). I think we should follow the > > CSS standard as much as possible. > > I think we should allow to set all property values. Defining separate > entries for all values is not feasible, for example PyDev, JDT, Android, > Perl, Git have its own editors and views with properties for their elements. > > Paul and I discussed that on EclipseCon and he suggested we advice using > this only for UI related properties but do not limited it to it. For example > with this approach you could use CSS to set the default selected buttons in > any view, e.g., EGit, Console, History, which I think would be very useful > to users and it is UI related. OK, but maybe instead of the construction: Preferences { org.eclipse.core.resources/refresh.lightweight.enabled:true } we can use the following one: .MPart#org-eclipse-egit-ui-RepositoriesView { color: black; border: 1px solid black; preference: 'org.eclipse.core.resources/refresh.lightweight.enabled=true', 'otherPropertyName1=value1', 'otherPropertyName2=value2'; } It better matches the CSS standard and we will be able to override the 'preference' property in other selectors Daniel
(In reply to Daniel Rolka from comment #10) > we can use the following one: > > .MPart#org-eclipse-egit-ui-RepositoriesView { > color: black; > border: 1px solid black; > > preference: 'org.eclipse.core.resources/refresh.lightweight.enabled=true', > 'otherPropertyName1=value1', 'otherPropertyName2=value2'; > } > > It better matches the CSS standard and we will be able to override the > 'preference' property in other selectors I like the proposal but preference in Eclipse are global, so I don't know how the rule would select the "best" fitting style. Maybe we can modify your suggestion so that we support properties only for CSS in MApplication? Something like: .MApplication{ preference: 'org.eclipse.core.resources/refresh.lightweight.enabled=true', 'otherPropertyName1=value1', 'otherPropertyName2=value2'; } What do you think?
(In reply to Lars Vogel from comment #11) > What do you think? Yes, it looks fine for me, Daniel
(In reply to Daniel Rolka from comment #12) > (In reply to Lars Vogel from comment #11) > > What do you think? > > Yes, it looks fine for me, > > Daniel However the selectors that express some application's state (with the tags, i.e. 'active', 'busy', ...) could also modify the properties - for instance we want to display some additional items in GUI (controlled by the preferences) when some .MPart gets some state Daniel
Is it just another property handler? <selector> { preference: 'org.eclipse.ui/PREF=true', 'org.eclipse.text.editors/A_FONT='name;size'; } That looks a mess. Can it be spread across lines? <selector> { preference: 'org.eclipse.ui/PREF=true'; preference: 'org.eclipse.text.editors/A_FONT='font: name;font-size: 8'; } Since it's primary purpose is for setting colors and fonts (at initially) how would the preference look for setting a font (we just pretend it's an inline style)? As a property, if you had 2 rules with a preference: wouldn't the CSS engine throw one of them away based on the selectors of the different rules? What about similar to color and font defs: org-eclipse-Preference#org-eclipse-ui/PREF { value: true; } org-eclipse-Preference#org-eclipse-text-editors/A_FONT { font: name; font-size: 8; } PW
Created attachment 241066 [details] editor prefs from http://eclipsecolorthemes.org/ Here are a list of prefs that we can use to test setting them from the pref page PW
(In reply to Paul Webster from comment #14) > Is it just another property handler? Yes. Basically the implementation of the feature doesn't seem to be complicated. We shouldn't have the issues with refreshing after updating the preference store since after the change the proper listeners will be notified. However we will have to fix the preference dialog to allow the users manually modify the preference values exposed by plugins and overridden by the CSS (without this change the CSS will always override the values) > > <selector> { > preference: 'org.eclipse.ui/PREF=true', > 'org.eclipse.text.editors/A_FONT='name;size'; > } > > That looks a mess. Can it be spread across lines? > <selector> { > preference: 'org.eclipse.ui/PREF=true'; > preference: 'org.eclipse.text.editors/A_FONT='font: name;font-size: 8'; > } Unfortunately it doesn't work since the first preference will be taken into account by the CSS engine only (actually by the Batik during parsing the style sheet). We have to have the unique property names > > Since it's primary purpose is for setting colors and fonts (at initially) > how would the preference look for setting a font (we just pretend it's an > inline style)? > > As a property, if you had 2 rules with a preference: wouldn't the CSS engine > throw one of them away based on the selectors of the different rules? > > What about similar to color and font defs: > > org-eclipse-Preference#org-eclipse-ui/PREF { > value: true; > } > > org-eclipse-Preference#org-eclipse-text-editors/A_FONT { > font: name; > font-size: 8; > } > > PW It depends on how far we want to go in this feature. Using the syntax above we will be able to override the property values per CSS theme. We have to use the similar construction to the ThemesExtension element in order to add the new preferences with the CSS (we have to know what we are looking for in the style sheet). However I would allow to define the preferences per CSS theme and selectors representing the application's state (i.e. .MPart.active) since it is more flexible to the user. Besides modifying the Colors/Fonts or showing/hiding some GUI items regarding the particular preference value (as I've mentioned in the comment 13), they can go further and for instance: - define some special text and update the proper widgets with it (see the snippet below) - define special data formatters for the particular state - limit the numbers of displayed rows in the viewers or highlight some rows that are important for the particular state and so on. I think, from the RCP developers point of view it can be very valuable feature. To simplify a bit the CSS syntax for the preferences we can use the following constructions: <selector> { preference: '#org-eclipse-ui/PRE', '#org-eclipse-text-editors/A_FONT'; -> We can use the 'space' as the delimiter of the list. Additionally we can use the new as well as the already existing preferences. } org-eclipse-Preference#org-eclipse-ui/PREF { value: true; } org-eclipse-Preference#org-eclipse-text-editors/A_FONT { font: name; font-size: 8; } .MPart { preference: '#org-eclipse-ui/loadingIdicatorVisible=false'; } .MPart.busy { preference: '#org-eclipse-ui/loadingIdicatorText', '#org-eclipse-ui/loadingIdicatorVisible=true'; } org-eclipse-Preference#org-eclipse-ui/loadingIdicatorText { value: 'Loading data, please wait'; } Daniel
(In reply to Daniel Rolka from comment #16) > > <selector> { > preference: '#org-eclipse-ui/PRE', '#org-eclipse-text-editors/A_FONT'; -> > We can use the 'space' as the delimiter of the list. Additionally we can use > the new as well as the already existing preferences. > > } > > org-eclipse-Preference#org-eclipse-ui/PREF { > value: true; > } > > org-eclipse-Preference#org-eclipse-text-editors/A_FONT { > font: name; > font-size: 8; > } > > .MPart { > preference: '#org-eclipse-ui/loadingIdicatorVisible=false'; > } > > .MPart.busy { > preference: '#org-eclipse-ui/loadingIdicatorText', > '#org-eclipse-ui/loadingIdicatorVisible=true'; > } > > org-eclipse-Preference#org-eclipse-ui/loadingIdicatorText { > value: 'Loading data, please wait'; > } > > Daniel I can prepare the initial version of the patch for the feature if we have the final version of the CSS syntax for it Daniel
(In reply to Daniel Rolka from comment #16) > Unfortunately it doesn't work since the first preference will be taken into > account by the CSS engine only (actually by the Batik during parsing the > style sheet). We have to have the unique property names So this means we can't really use preference:, since another rule that provided a completely different preference this way would cause the CSS engine to throw it away. > However I would allow to define the preferences per CSS theme and selectors > representing the application's > state (i.e. .MPart.active) since it is more flexible to the user. Besides > modifying the > Colors/Fonts or showing/hiding some GUI items regarding the particular > preference value (as I've mentioned in the > comment 13), they can go further and for instance: The only reason I want to enable this feature is so that a CSS theme can set editor preferences, just like eclipsecolorthemes.org. I don't want people to think CSS is a back door for setting eclipse preferences, since it should only deal with appearance-related preferences. > To simplify a bit the CSS syntax for the preferences we can use the > following constructions: > > <selector> { > preference: '#org-eclipse-ui/PRE', '#org-eclipse-text-editors/A_FONT'; -> > We can use the 'space' as the delimiter of the list. Additionally we can use > the new as well as the already existing preferences. > > } This is the one that won't work with CSS cascade rules (it is far too easy for users to break their own preferences or a parent style sheet's preferences. > > org-eclipse-Preference#org-eclipse-ui/PREF { > value: true; > } > > org-eclipse-Preference#org-eclipse-text-editors/A_FONT { > font: name; > font-size: 8; > } This is consistent with our color and font definitions. > > .MPart { > preference: '#org-eclipse-ui/loadingIdicatorVisible=false'; > } > > .MPart.busy { > preference: '#org-eclipse-ui/loadingIdicatorText', > '#org-eclipse-ui/loadingIdicatorVisible=true'; > } I wouldn't want to tie preferences (which are global) to the runtime state of the CSS. That could cause a lot of thrashing in the system, especially if the same rule was applied to multiple widgets. PW
Created attachment 241126 [details] Syntax Coloring vs. CSS Is there some reason for not just using CSS like it's meant to be used; to put colors and fonts on some texts? You know, the task it was created for? Is inventing a way of styling some SQLite databases with non-standard CSS really easier than doing what someone using HTML & CSS would do: be putting some span:s around text blocks and adding meaningful CSS class combinations to them? Because I just tried that as a proof-of-concept and don't see any meaningful difference in the attached comparison screenshot between the Syntax Coloring preview window and the HTML+CSS mock-up inside a browser.
Created attachment 241127 [details] Source 'code' for the mock-up Here's the self-contained mock-up used in the comparison. Your results may vary based on locally available fonts and system DPI settings, for example. Take a loot inside anyway, and see the selectors for methods. Where's 'declared static method', for example? If going with preferences you'll have to fight CSS both ways, first to add CSS styling to stored preferences, then adding exclusions for several perfectly reasonable combinations that don't have a setting in preferences.
(In reply to Timo Kinnunen from comment #19) > Created attachment 241126 [details] > Syntax Coloring vs. CSS > > Is there some reason for not just using CSS like it's meant to be used; to > put colors and fonts on some texts? Any new views and editors are free to do their styling with CSS. The views and editors that exist today don't, so to style them we can either set the preferences (possible to do in M7) or re-write each individual view/editor styling (possible to do by Mars+1). So we're looking at updating the existing styling via preferences. PW
*** Bug 430996 has been marked as a duplicate of this bug. ***
Lars, Do you work on it or I can take it? Daniel
(In reply to Daniel Rolka from comment #23) > Lars, > > Do you work on it or I can take it? > > Daniel Please take it.
Created attachment 241477 [details] CSS style sheet used during testing the patch I've pushed the initial version of the patch to Gerrit: https://git.eclipse.org/r/#/c/24266/ It seems to be working fine, but I have to perform more tests of it (especially the manual overriding of the preferences with the preference dialog) Unfortunately we are not so flexible with the CSS syntax for it as I was initially thinking - we have to have the fixed CSS property name (i.e. preferences), however we can try to modify the syntax slightly. The separator for the preferences is any valid CSS list separator (i.e. new line, the comma is also accepted) The preferences listed in the CSS file are in the same form as stored in the workspace (i.e. in the file <WORKSPACE>.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.jdt.ui.prefs) -> see the 'CSS style sheet used during testing the patch' attachment Daniel
(In reply to Daniel Rolka from comment #25) > Created attachment 241477 [details] > CSS style sheet used during testing the patch AFAIK we don't need all that workbench stuff. See how /org.eclipse.e4.core.di.extensions/src/org/eclipse/e4/core/di/internal/extensions/PreferencesObjectSupplier.java deals with preferences, using IEclipsePreferences and org.eclipse.core.runtime.preferences.IPreferencesService This will allow it to work with Eclipse4 applications. > > I've pushed the initial version of the patch to Gerrit: > https://git.eclipse.org/r/#/c/24266/ So the proposed style is: PreferenceNode#org-eclipse-jdt-ui-preferences-JavaEditorColoringPreferencePage { preferences: 'semanticHighlighting.abstractClass.color=128,255,0' 'semanticHighlighting.abstractClass.color=128,255,1' 'semanticHighlighting.abstractClass.enabled=true' 'java_bracket=0,255,255' 'java_bracket_bold=true' 'java_bracket_italic=true' 'java_bracket_strikethrough=true' 'java_bracket_underline=' /*reset to default value*/ } If we're using the IEclipsePreferences or IPreferencesService it would probably have to be something like: PreferenceNode#org-eclipse-jdt-ui { preferences: 'semanticHighlighting.abstractClass.color=128,255,0' 'semanticHighlighting.abstractClass.color=128,255,1' 'semanticHighlighting.abstractClass.enabled=true' 'java_bracket=0,255,255' 'java_bracket_bold=true' 'java_bracket_italic=true' 'java_bracket_strikethrough=true' 'java_bracket_underline=' /*reset to default value*/ } What happens if 2 included style sheets both provide the PreferenceNode#org-eclipse-jdt-ui rule? PW
(In reply to Paul Webster from comment #26) > (In reply to Daniel Rolka from comment #25) > > Created attachment 241477 [details] > > CSS style sheet used during testing the patch > > AFAIK we don't need all that workbench stuff. See how > /org.eclipse.e4.core.di.extensions/src/org/eclipse/e4/core/di/internal/ > extensions/PreferencesObjectSupplier.java deals with preferences, using > IEclipsePreferences and > org.eclipse.core.runtime.preferences.IPreferencesService > > This will allow it to work with Eclipse4 applications. OK, it sounds good to me. I will update the patch respectively. > > > > > I've pushed the initial version of the patch to Gerrit: > > https://git.eclipse.org/r/#/c/24266/ > > So the proposed style is: > PreferenceNode#org-eclipse-jdt-ui-preferences- > JavaEditorColoringPreferencePage { > preferences: > 'semanticHighlighting.abstractClass.color=128,255,0' > 'semanticHighlighting.abstractClass.color=128,255,1' > 'semanticHighlighting.abstractClass.enabled=true' > 'java_bracket=0,255,255' > 'java_bracket_bold=true' > 'java_bracket_italic=true' > 'java_bracket_strikethrough=true' > 'java_bracket_underline=' /*reset to default value*/ > } > > If we're using the IEclipsePreferences or IPreferencesService it would > probably have to be something like: > > PreferenceNode#org-eclipse-jdt-ui { > preferences: > 'semanticHighlighting.abstractClass.color=128,255,0' > 'semanticHighlighting.abstractClass.color=128,255,1' > 'semanticHighlighting.abstractClass.enabled=true' > 'java_bracket=0,255,255' > 'java_bracket_bold=true' > 'java_bracket_italic=true' > 'java_bracket_strikethrough=true' > 'java_bracket_underline=' /*reset to default value*/ > } > > What happens if 2 included style sheets both provide the > PreferenceNode#org-eclipse-jdt-ui rule? They will be merged in such case (the cascading policy) > > PW Daniel
Created attachment 241722 [details] CSS style sheet used during testing the patch (v2)
(In reply to Daniel Rolka from comment #25) > Created attachment 241477 [details] > CSS style sheet used during testing the patch > > I've pushed the initial version of the patch to Gerrit: > https://git.eclipse.org/r/#/c/24266/ > I've pushed the 2nd part of the patch to Gerrit - https://git.eclipse.org/r/#/c/24860/ Daniel
Created attachment 241905 [details] Dark editor prefs as CSS I tested by adding the above content to the CSS editor in the Appearance pref page. PW
Created attachment 241964 [details] Dark editor prefs as CSS (v2)
Created attachment 241965 [details] CSS style sheet used during testing the patch (v3)
Released as: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=02d5c01c99f34ee0b77cf9f9004c121acaa4fd25 Daniel
We need some minimal test cases for this new functionality. PW
(In reply to Paul Webster from comment #34) > We need some minimal test cases for this new functionality. > > PW Released as: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=7d632536353ddbe645c85afd75a328b5e35dfd7a Daniel
From Daniel about firing the Theme event in the PartRenderingEngine: It works fine in my local env (Windows 7). I think I've seen the similar issue working on the version of the patch with the Addons, but the latest version always worked for me as expected. Anyway, I've prepared two patches that should solve the issue in better way: 1) https://git.eclipse.org/r/#/c/25159/ - I assume that we don't have all pieces in place during 1st 'IThemeEngine.Events.THEME_CHANGED' event, sent during processing the 'themeEngine.restore(cssTheme)' method. So maybe the patch will be sufficient 2) https://git.eclipse.org/r/#/c/25158/ - we can send some extra event when we are initializing the styling and style the preferences first time, handling it. The StylingPreferencesHandler will be invoked 2nd time when the event 'IThemeEngine.Events.THEME_CHANGED' occurs, but there won't be modified any preferences since all changes will be already in place after considered extra event. The 2nd run will be treat as the modification of the preferences by the user so it is not so bad Please check if the patches work for you and let me know if you would like to apply one of them.
(In reply to Paul Webster from comment #36) > From Daniel about firing the Theme event in the PartRenderingEngine: > > It works fine in my local env (Windows 7). I think I've seen the similar > issue working on the version of the patch with the Addons, but the latest > version always worked for me as expected. Anyway, I've prepared two patches > that should solve the issue in better way: If it works fine in both cases (new workspace with prefs in the default css and used workspace with the prefs added after the fact) without that call then why not remove it. PW
Released as: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b8627472bdf076d3b4e9f7ded344e908efd132d1 Daniel
Verified in the build: I20140428-2000 There is small refreshing issue that was reported with the Bug 433765 Daniel
We also have a consumer in the platform, in the dark theme I use it to style org.eclipse.ui. UI relevant preference values for the dark theme.
