Community
Participate
Working Groups
Created attachment 276033 [details] Custom widget with not style. Right now, to style custom widgets it is required to extend the themes. The proposal is to allow custom widgets to specify an already existent CSS class to be used to style him. Something like this: class MyCanvas extends Canvas { public MyCanvas(Composite parent, int style) { super(parent, style); setData("org.eclipse.e4.ui.css.CssClassName", "Canvas"); } } So, the theme engine should apply the style defined for the class Canvas to the all the instances of MyCanvas. In the attached image, you can see how custom Composite and Canvas are not styled.
Hi Arian, as discussed via the e4 mailing list, this is a good idea. Please provide a Gerrit for org.eclipse.ui.themes/dark/e4-dark_globalstyle.css adding the ".Canvas" and ".Composite" selector to the first selector. See http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html#exericse-eclipse-user-creation-and-gerrit-server-configuration for a description of the necessary setup.
Please also add a corresponding test to org.eclipse.e4.ui.tests.css.swt.CompositeTest
Should CSS inheritance apply here?
(In reply to Mickael Istria from comment #3) > Should CSS inheritance apply here? No.
Is there a way to just build only the "org.eclipse.ui.themes" bundle. The mvn clean is running a lot of tests that in the end, one fails and the build is stopped.
(In reply to Arian Fornaris from comment #5) > Is there a way to just build only the "org.eclipse.ui.themes" bundle. The > mvn clean is running a lot of tests that in the end, one fails and the build > is stopped. Use -DskipTests=true But you can also test in a runtime Eclipse as describe here: http://www.vogella.com/tutorials/EclipsePlugin/article.html#runtimeeclipse_starting
Hi Lars, ok, I will try in that way. By the way, a workaround from Mickael Istria (posted in the email list): > I the parent is a composite, did you try parent.setBackgroundMode(SWT.INHERITS_FORCE) ? And yes, it works with Composite and Canvas.
I prefer our solution to allow to set the CSS class. I think this is better compare to modifying the swt code.:-)
(In reply to Lars Vogel from comment #8) > I prefer our solution to allow to set the CSS class. I think this is better > compare to modifying the swt code.:-) I think there is something fundamentally wrong on the usage of CSS done by SWT. CSS is by definition "cascading" and that's what makes it very practical. SWT is not (there is inheritance in styling). Hence let's not pretend CSS is the solution to the problem of inheriting colors or other style things that an adopter is very likely to prefer inherited. Adding proper inheritance/cascading of the main style configuration in SWT will result in much cleaner, agile and customizable, and higher quality applications than trying to use CSS to fix (workaround?) every style issue caused by lack of inheritance.
Michael, sorry but please open new bugs for "reinventing CSS", this bug is about opting in for customer widgets into the styling of Composite and Canvas. Solution is trivial and will improve the situation.
Created attachment 276096 [details] Composite instance
Created attachment 276097 [details] Composite subclass instance
Hi, Sorry the delay, I am traveling to a conference. I did some tests and found some "solutions". Solution 1: I added the .Canvas and .Composite class to the first rule of the CSS file, but it does not work 100%. You can see in the image "Composite sublass instance.png" (https://bugs.eclipse.org/bugs/attachment.cgi?id=276097), the custom composite is styled, but not with the right color. If I do not subclass the composite, then it is styled well. See image "Composite instance.png" (https://bugs.eclipse.org/bugs/attachment.cgi?id=276097). I think to use a .Composite or .Canvas class is not the best solution. Third party themes are not going to work if they don't include these classes in the right rules. Solution 2: I created this rule: .Transparent { background-color: inherit; color: inherit; } If I set the Transparent class to the custom Composite and Canvas then it works. Maybe, as a good practice, all themes should include that rule, or we should create a bootstrap CSS theme with this rule, and import it in all the themes. Solution 3: Other possible solution is to allow the user to set the "Tag Name" of a widget. I mean, if you do something like this: class MyWidget extends Composite { public MyComposite(...) { setData("org.eclipse.e4.ui.css.CssElementName", "Composite"); } } Then, the "Composite" query selector will match the instances of MyWidget. Solution 4: Inline CSS. In HTML you can set the style of a DOM element in the element definition: <div style="color: blue"></div> We can do the same in SWT, so the user can do something like this: class MyWidget extends Composite { public MyComposite(...) { setData("org.eclipse.e4.ui.css.CssStyle", "background-color: inherit; color: inherit;"); } } Solution 5: In the meantime, I will use this workaround from Mickael Istria, to "inherite" the background/foreground colors from the parent: class MyWidget extends Composite { public MyComposite(Composite parent, int style) { super(parent, style); parent.setBackgroundMode(SWT.INHERIT_FORCE); addPaintListener(new PaintListener() { @Override public void paintControl(PaintEvent e) { MyWidget.this.setForeground(parent.getForeground()); } }); } } Best regards, Arian.
Thanks Arian. We need Solution 1 in platform to allow Solution 3 for customer widgets. Can you upload a Gerrit for the change in the platform CSS?
Hi Lars, I was offline for several days. I will look at this soon. Thanks Arian
Hi Lars, I don't see how Solution 1 (setting a CSS class to a widget) is related to Solution 3 (setting a CSS "tag name" to a widget). Both are independent. As I commented before, I think solution 1 is not the best.
(In reply to Arian Fornaris from comment #16) > Hi Lars, > As I commented before, I think solution 1 is not the best. Solution 1 is an easy way to allow plug-in developer to opt into the platform styling and would work for all possible themes, as they will use the same styling as Composite and Canvas as defined by the theme. Developer could then say: myWidget.setData("org.eclipse.e4.ui.css.CssClassName", "Composite"); or myWidget.setData("org.eclipse.e4.ui.css.CssClassName", "Canvas"); to use the same styling. I think that is the solution 3.
well, using a .Canvas and .Composite class did not work for me (the widgets gets darker, but not with the right colors: https://bugs.eclipse.org/bugs/attachment.cgi?id=276097 ). I am pretty sure because I need to add more rules to the dark stylesheet. Yet I think a better solution is tu add new rule (Solution 2): .Transparent { background-color: inherit; color: inherit; } Then the users can use the Transparent class and it just works. So the only thing we have to do is to create a common.css file that is inherited by all other CSS files.
(In reply to Arian Fornaris from comment #18) > well, using a .Canvas and .Composite class did not work for me (the widgets > gets darker, but not with the right colors: > https://bugs.eclipse.org/bugs/attachment.cgi?id=276097 ). I am pretty sure > because I need to add more rules to the dark stylesheet. > > Yet I think a better solution is tu add new rule (Solution 2): > > .Transparent { > background-color: inherit; > color: inherit; > } > > > Then the users can use the Transparent class and it just works. So the only > thing we have to do is to create a common.css file that is inherited by all > other CSS files. Please upload a Gerrit patch so that I can check.
> Please upload a Gerrit patch so that I can check. Ok I will.
Hi Lars, I am trying to push the changes but I get this error: Counting objects: 9, done. Delta compression using up to 8 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.13 KiB | 288.00 KiB/s, done. Total 9 (delta 8), reused 0 (delta 0) remote: Resolving deltas: 100% (8/8) remote: Processing changes: refs: 1, done remote: (W) 5a14593: commit subject >50 characters; use shorter first paragraph remote: (W) 5a14593: too many commit message lines longer than 72 characters; manually wrap lines remote: ---------- remote: Reviewing commit: 5a145935 remote: Authored by: Arian Fornaris <boniatillo@gmail.com> remote: remote: The author is not a committer on the project. remote: The author has a current Eclipse Contributor Agreement (ECA) on file. remote: error: The author has not "signed-off" on the contribution. remote: If there are multiple commits, please ensure that each commit is signed-off. remote: Please see http://wiki.eclipse.org/ECA To https://git.eclipse.org/r/platform/eclipse.platform.ui ! [remote rejected] HEAD -> refs/for/master (The contributor must "sign-off" on the contribution.) error: failed to push some refs to 'https://git.eclipse.org/r/platform/eclipse.platform.ui'
(In reply to Arian Fornaris from comment #21) > Hi Lars, > > I am trying to push the changes but I get this error: > remote: error: The author has not "signed-off" on the contribution. > remote: If there are multiple commits, please ensure that each commit is > signed-off. Sounds like you forgot to sign off the commit. If you use the Git staging view, simply amend the commit and press the "Added Sign-Off by" button in the toolbar.
Well, I revoked the ECA, because it shows an expiration message. Now it says it takes some time to file a new ECA.
New Gerrit change created: https://git.eclipse.org/r/132102
Hi Lars, You can review the changes here: https://git.eclipse.org/r/#/c/132102/ I just added the Transparent rule to the base styles.
(In reply to Arian Fornaris from comment #25) > Hi Lars, > > You can review the changes here: > > https://git.eclipse.org/r/#/c/132102/ > > I just added the Transparent rule to the base styles. Please see feedback in the Gerrit.
Arian, any plans to provide tests?
Sorry Lars, I cannot contribute at this moment. I sent you a private message.
Mass change, please reset target if you still planning to fix this for 4.11.
Please set the target milestone back to 4.12 if you still intend to fix this for 4.12.
Hi, I solved this by creating a "stylesheet" extension. So I add my own CSS to the current themes and include the ".Transparent" rule, and use it in my custom components. I think third-party plugin developers can I use this technique. Do you think is it valid to add the .Transparent rule to the Eclipse base code?
(In reply to Arian Fornaris from comment #31) > I think third-party plugin developers can I use this technique. It would be great if you could document it in some blog post or similar. > Do you think is it valid to add the .Transparent rule to the Eclipse base > code? I have no strong objection personally, but I think we usually prefer adding specific customization if and only if we use them in the workbench/IDE.
(In reply to Mickael Istria from comment #32) > > It would be great if you could document it in some blog post or similar. > Ok, let me see where I can post it. Maybe in Medium. > > I have no strong objection personally, but I think we usually prefer adding > specific customization if and only if we use them in the workbench/IDE. I agree. For that reason, I think this bug can be closed. The workbench/IDE does not need to use this (I guess), because it is not using it right now.
Closing as per comment 33.
