Community
Participate
Working Groups
Created attachment 273039 [details] Screencast showing the issue The context help in wizards (when pressing the ?-Button on the Wizard) is not styled correctly. See attached screenshot. The help-view on the other is styled correctly already.
Created attachment 273040 [details] Help in Help-View is styled correctly
I debugged this and found the root cause. The issue is in FormToolkit#createScrolledForm. During the creation of the ScrolledForm the theme engine correctly sets the colors. Then the FormToolkit overwrites them again by the call to form.setBackground(colors.getBackground()); For debugging purposes I changed the WizardDialog to be modeless by changing in the constructors the line. setShellStyle(SWT.CLOSE | SWT.MAX | SWT.TITLE | SWT.BORDER | SWT.APPLICATION_MODAL | SWT.RESIZE | getDefaultOrientation()); to setShellStyle(SWT.CLOSE | SWT.MAX | SWT.TITLE | SWT.BORDER | SWT.MODELESS | SWT.RESIZE | getDefaultOrientation()); After this you can use the CSS-Spy to inspect the tray. When I open the CSS-Scratchpad while the wizard tray is open (and is showing the partly white background as in attachment 273039 [details]) and press "Apply" in the "CSS Scratch pad" without putting any additional CSS in there the styling of the Tray is corrected. This shows that the CSS is correct (and applied correctly in the first place) but colors are changed back by the FormToolkit. This is the same issue as in https://bugs.eclipse.org/bugs/show_bug.cgi?id=514318#c10 One possible fix could be to somehow suspend the CSS-Engine (at least the property setting part) between the beginn of the FormToolkit#createScrolledForm method and let the CSS-Engine apply it's property changes directly before the method returns. By this the "wrong" colors set with form.setBackground(colors.getBackground()); form.setForeground(colors.getColor(IFormColors.TITLE)); would be overwritten with the correct values from the CSS. But this is just a first thought. I don't know if this would have other side-effect and I also don't know if the CSS-Engine does provide the needed functions to delay the execution of the property-setting temporarily. Adding Brian de Alwis and Till Brychcy as they may have knowledge in the CSS and Forms area. Brian and Till: Any remarks from your side?
I wonder if a saner approach might be to change how the Forms toolkit retrieves colours to consult the CSS engine?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=531422 had the same issue. There is could be work-arounded by the fact that JDT set the foreground / background colors to null ( see JavaPlugin#getDialogsFormToolkit). I tried the same pattern by setting the background color to null in HelpTray#createContents and adding a null-check in FormToolkit#createScrolledForm so that the background is only set when getBackground() does not return null. This looked good in the dark theme (because the CSS engine does set all the colors). But this leads to artefact in the light theme (as there the CSS engine does not set all the colors. So this really is a conceptual issue with the CSS styling and the FormToolkit. Any ideas how to solve this?
(In reply to Brian de Alwis from comment #3) > I wonder if a saner approach might be to change how the Forms toolkit > retrieves colours to consult the CSS engine? How could that be done?
My thoughts were that we could have FormColors#initialize*() somehow pull values from the CSS with something like org.eclipse.e4.ui.internal.workbench.swt.CSSRenderingUtils#getCSSValue(). Ideally we'd do this in such a way that neither org.eclipse.ui.forms nor org.eclipse.e4.ui.workbench.swt are exposed to each other. Fundamentally the problem is that the we want to allow the CSS to overrule the SWT System/OS default colours. Ideally this the mechanism should be useful for other widget libraries too. Here's one approach that might work: - have the SWT CSS engine add a colour-lookup dictionary on Display that is populated from the CSS (via the getData()/setData()) - FormColors#getSystemColor() will first try looking up a colour in that dictionary It might be worth having that colour-lookup be provided with a context object, like the FormColors class name, so that it could use that object to key off the CSS (e.g., specific colours for Forms). What do you think?
(In reply to Brian de Alwis from comment #6) > My thoughts were that we could have FormColors#initialize*() somehow pull > values from the CSS with something like > org.eclipse.e4.ui.internal.workbench.swt.CSSRenderingUtils#getCSSValue(). > Ideally we'd do this in such a way that neither org.eclipse.ui.forms nor > org.eclipse.e4.ui.workbench.swt are exposed to each other. > > Fundamentally the problem is that the we want to allow the CSS to overrule > the SWT System/OS default colours. Ideally this the mechanism should be > useful for other widget libraries too. > > Here's one approach that might work: > > - have the SWT CSS engine add a colour-lookup dictionary on Display that > is populated from the CSS (via the getData()/setData()) > > - FormColors#getSystemColor() will first try looking up a colour in that > dictionary > > It might be worth having that colour-lookup be provided with a context > object, like the FormColors class name, so that it could use that object to > key off the CSS (e.g., specific colours for Forms). > > What do you think? As far as I understand the CSS engine does not have fixed values for e.g. a Label but the color is dependent also on the parents of the label (a label inside a composite my have a different color then a label inside a composite inside another composite). But FormToolkit currently does some color-magic based on system colors. Does that work together? Keep in mind: FormToolkit is not only used on form editor but also on "normal" SWT dialogs.
A simpler way might be to use preferences in forms for this and use CASE to style them. Also, forms cannot have a dependency to the CSS engine as it is used standalone.
(In reply to Lars Vogel from comment #8) > A simpler way might be to use preferences in forms for this and use CASE to > style them. So you mean to replace all the magic in initializeColorTable() with definitions from the different CSSes? > Also, forms cannot have a dependency to the CSS engine as it is used > standalone. What means "standalone"?
(In reply to Matthias Becker from comment #9) > (In reply to Lars Vogel from comment #8) > > A simpler way might be to use preferences in forms for this and use CASE to > > style them. > So you mean to replace all the magic in initializeColorTable() with > definitions from the different CSSes? > > > Also, forms cannot have a dependency to the CSS engine as it is used > > standalone. > What means "standalone"? Look in the manifest for its dependencies, I think it only requires SWT and maybe JFace.
> As far as I understand the CSS engine does not have fixed values for e.g. a Label but the color is dependent also on the parents of the label (a label inside a composite my have a different color then a label inside a composite inside another composite). > But FormToolkit currently does some color-magic based on system colors. > Does that work together? Sorry, I'm doing some wild hand-waving. At its essence what I'm suggesting is adding a level of indirection between how FormToolkit/FormColor initializes its colour values from SWT to allow these values to be over-ridden with CSS. My suggestion above was to add a colour look-aside table, and provide an implementation that can pull values from the CSS. "Fixed" values can be provided in the CSS by querying against some fixed class. Lars' suggestion (IIUC) is to instead pull values from colour preferences, and thereby benefit from the existing preferences bridging support in the CSS. Lars' suggestion seems easier.
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.
Still valid
