Community
Participate
Working Groups
In order to better support the CSS required by e4, the editor should allow for the name of the CSS file to be specified and synchronized with the appropriate value in the plugin.xml.
Out of time for 4.4. I'm confused how this would work. An option in the product editor would look out of place, especially as not all products may be using e4 with a css file.
(In reply to Curtis Windatt from comment #1) > Out of time for 4.4. > > I'm confused how this would work. An option in the product editor would look > out of place, especially as not all products may be using e4 with a css file. As I understand it, the org.eclipse.runtime.core.products extension point lets you define either the "applicationCSS" property for fixed styling, or the "cssTheme" property for the default theme when you are letting the user change themes. It makes sense to me that we could define either of these items (default theme or the css for the application) in the product editor, similar to defining window images, about images, etc. I do think that defining the themes themselves here would not make much sense conceptually, as there may be many of these and the definitions would likely be specified in some UI plugin (not necessarily the product plug-in).
I pushed an initial pass at this to Gerrit. https://git.eclipse.org/r/26768 This is not ready for PDE review, but is pushed to Gerrit for Pascal and I to evaluate the UI together. This first pass assumes the product uses static CSS via the "applicationCSS" property in the products extension. While building a small sample application to test this, I ran into a number of barriers that I think this implementation can help with: - it lets you choose any CSS in the workspace - it ensures that your build.properties includes the CSS when the plugin is synchronized - it ensures the proper path is used in the extension point so that the CSS can be found (there are reports of plugin relative paths not working from jar files. Indeed, my exported product would not work until I used full "plugin" based paths. (See http://stackoverflow.com/questions/19357768/eclipse-rcp-css-styling-does-not-work-after-export http://www.eclipse.org/forums/index.php/t/457837/ or search on "CSS eclipse not working on export") There do seem to be many places to get this wrong, and I'm not sure of the cause of the relative path problems, but I did observe that CSS would be honored on launch but not on export until all these details were implemented. So I think this is of value for someone who wants to use simple static CSS. To support themes we have to be careful to draw the line in the right place. I could imagine letting the user supply the theme id, but I'm not sure it's appropriate to be checking all the theme definitions, files, and fixing up build.properties, etc...
cc'ing Lars Vogel for an opinion from a e4 UI point of view. We received a request to let developers specify a CSS file in the PDE product editor, which I am assuming maps to the use of the "applicationCSS" static styling in the products extension. However, it seems that the CSS-based theming has a lot more traction. I can't find a definitive statement that "applicationCSS" is discouraged and it does work. Lars, can you comment at all on the state of "applicationCSS" static styling in e4 and whether it would make sense to support the specification of static styling in the product editor? If it does not, then I can only really imagine specifying the default css theme (id) from the product editor.
The latest patch set in Gerrit is ready to review at https://git.eclipse.org/r/#/c/26768/ Note that it depends on the code in a previous change set. https://git.eclipse.org/r/#/c/26547/ ( bug 426530 ) Bug 426528 should be reviewed and merged first before attempting to use this cdoe.
Also note that we are indeed supporting the static application styling support (applicationCSS) at the product level. The user is expected to use the plugin manifest editor to specify themes as is done today.
Note: the sample files provided in bug 426530 can also be used to test this functionality. You can switch the CSS file between css/colorful.css and css/default.css in the product editor, and you'll see that the launched or exported application honors these settings.
Vikas has started doing a more in-depth review and I have forwarded my initial comments to him, but I wanted to express my major concern, which is that this feature doesn't integrate well with the product editor. As you always need an ini file in the end, wouldn't it make more sense for this to be a wizard? One you could access by right clicking on an epf file, right clicking on a product file, or by a link somewhere in the product editor?
Created attachment 244091 [details] screenshot of the CSS functionality This is a screenshot of the new functionality. The CSS section appears on the bottom of the "Customization" page. The customization page appears via bug 426530.
(In reply to Curtis Windatt from comment #8) > Vikas has started doing a more in-depth review and I have forwarded my > initial comments to him, but I wanted to express my major concern, which is > that this feature doesn't integrate well with the product editor. > > As you always need an ini file in the end, wouldn't it make more sense for > this to be a wizard? One you could access by right clicking on an epf file, > right clicking on a product file, or by a link somewhere in the product > editor? I think you are referring to bug 426530?
(In reply to Susan McCourt from comment #10) > (In reply to Curtis Windatt from comment #8) > > Vikas has started doing a more in-depth review and I have forwarded my > > initial comments to him, but I wanted to express my major concern, which is > > that this feature doesn't integrate well with the product editor. > > > > As you always need an ini file in the end, wouldn't it make more sense for > > this to be a wizard? One you could access by right clicking on an epf file, > > right clicking on a product file, or by a link somewhere in the product > > editor? > > I think you are referring to bug 426530? Yes, I'll copy the comment there.
I just rebased this patch now that bug 426530 has been merged. https://git.eclipse.org/r/26768 Comment #7 is still valid for how to test the functionality.
(In reply to Susan McCourt from comment #4) > Lars, can you comment at all on the state of "applicationCSS" static styling > in e4 and whether it would make sense to support the specification of static > styling in the product editor? If it does not, then I can only really > imagine specifying the default css theme (id) from the product editor. Sorry missed that request. applicationCSS would be useful for the "simple" case in which the customer has only one styling defined and has no need to style the splash screen. Having support for it via the product editor would be helpful. Even better would be support for the cssTheme property which allow to set default theme. I think that would be even more useful for RCP and Eclipse IDE based products.
(In reply to Lars Vogel from comment #13) > Sorry missed that request. applicationCSS would be useful for the "simple" > case in which the customer has only one styling defined and has no need to > style the splash screen. Having support for it via the product editor would > be helpful. Thanks, Lars. The product editor already provides a page for specifying the splash image, so this is intended for that kind of simple case. An RCP product where the styling is static, and other splash/window images/about images are specified at the product level. It is the missing piece of branding for RCP product customers. > > Even better would be support for the cssTheme property which allow to set > default theme. I think that would be even more useful for RCP and Eclipse > IDE based products. The theme is useful for apps where the user is exposed to the theme concepts, but we felt there wasn't as much value added here since you have to build the themes outside of the product editor, and there is less to "get wrong" when you specify a theme id (vs. the applicationCSS where there were lots of tricks about getting the paths, etc. correct.)
My usual quick review: 1) Browse is missing ... again 2) Browse action is inconsistent between workspace files and file system. This might be correct, but I wanted to point it out. Is it more likely that the CSS file will be in the workspace vs the .epf file? 3) "You must... ensure the CSS file" then a line break, then "is referenced". Why is there a line break here? The description for the section in on a single line. 4) The "You must synchronize" text doesn't sufficiently explain what it is doing. "is referenced by the plug-in"? What does this mean? 5) I recommend removing the () parens around "The application...". It is already a separate sentence.
(In reply to Curtis Windatt from comment #15) > My usual quick review: > 1) Browse is missing ... again will fix. > 2) Browse action is inconsistent between workspace files and file system. > This might be correct, but I wanted to point it out. Is it more likely that > the CSS file will be in the workspace vs the .epf file? Yes, because the CSS file has to be there in the built product in order to be used by the platform. It's part of the product. Whereas, the .epf file is just an input into a "conversion" that will end up putting the preferences in your plugin file (which is a workspace file). So the input can be anywhere, the output is in the workspace and built into the product. > 3) "You must... ensure the CSS file" then a line break, then "is > referenced". Why is there a line break here? The description for the > section in on a single line. will fix. > 4) The "You must synchronize" text doesn't sufficiently explain what it is > doing. "is referenced by the plug-in"? What does this mean? will elaborate. > 5) I recommend removing the () parens around "The application...". It is > already a separate sentence. ok. I'll ping here when there's a new update.
(In reply to Susan McCourt from comment #16) > I'll ping here when there's a new update. I pushed a new patch to https://git.eclipse.org/r/#/c/26768 To fix the problem with the word wrap, I had to change the layout used in the section, which has to ripple all the way up to the page in order to work. So you'll see some new changes in CustomizationPage and PreferencesSection that are there to support the use of a different layout (TableWrapLayout) so that the form text will wrap properly. Besides the layout changes, I updated the strings as suggested.
I'm happy with this last iteration. Approved and merged with master http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=c02617456399307d291e9d928e6d83ff734247e7
thanks, Curtis.
Verified on Mars 4.5 eclipse-SDK-N20140901-2000-win32-x86_64
