Community
Participate
Working Groups
This is a reminder/placeholder for work that has been ongoing/pending but I can't find a matching report. Runtime has added IProduct to model the default primary feature and IBundleGroup to model features. The UI gets various bits of information from the original entities and needs to adapt to the new structures. After consulting with Nick, both IProduct and IBundleGroup were left open ended and UI ignorant. Rather they provide a general getProperty() method. The valid key value pairs are to be defined by the consumers/users of the objects. So the UI should define the form of the information it needs for the product branding (e.g., windowImage, ...) and the about dialog. I don't know where this should be specified but the update team for example will need to know how to map the about.ini information onto IProducts and similarly, how to populate IBundleGroups.
For IProduct, the properties include: - app name (a tag for the SWT Display, used on X systems) - product name - shown in the window title in the SDK, e.g. "Eclipse SDK" - also on some actions (e.g. About) - about text and about image - shown in the about dialog (which currently is in the IDE layer) - window image - shown in the top left corner of workbench windows For IBundleGroup, we'll have: - image - shown in the row below the about image in the about dialog - tip and tricks href (IDE layer) - welcome page URL (IDE layer) - welcome perspective id (IDE layer) We have discussed removing dependencies on IProduct and IBundleGroup from the Workbench proper, and obtaining the generic properties (e.g. product name, window image) from the WorkbenchAdvisor (or allowing it to configure these on the IWorkbenchConfigurer). However, I'm having second thoughts about this now. We should probably have a single story for how these properties are obtained, common across all RCP apps.
Not quite sure what you mean about removing the dependency on IProduct and IBundleGroup. These interfaces are there exclusively for the UI. If you are not going to use them then we will delete them. Not sure how the about dialog will get populated. Assuming I got it wrong and you are going to use these at some level, teams like update need the exact keys they should have in the getProperty() collection when they produce an IProduct and IBundleGroup.
Need to define constant pools IProductConstants and IBundleGroupConstants in new package org.eclipse.ui.branding, with definitions for the existing properties used from about.ini. Should also define a windowImages property for bug 53172.
Re comment #2, the about dialog will be changed to use IProduct and IBundleGroup as soon as we can get the properties we need from here. I assume Dorian is waiting on us for the constant defs. Dorian, do you know when the change on your side will be made assuming we can get you the defs by Monday? We'll also change to get the product name and icon from IProduct. But what I was debating here is whether this should be done by the Workbench proper or by the application. That is, should the Workbench always just go to IProduct for these, or should it be the application's responsibility to configure the Workbench with these (it would be free to use IProduct or set them directly). Jeff, do you see any problem with giving the app flexibility here? It would allow simple RCP apps to be able to configure the Workbench without requiring a product provider or bundle group provider.
Nick, I see a problem with locating constants in org.eclipse.ui.branding, because the IProduct/IBundleGroup implementations are currently in update.configurator which has no ui dependencies. I have no problem moving them up to update.ui, but that is only easy to do for IProduct because it is contributed via an extension, but the IBundleGroup is done via registration and update.ui may not be running when you need it. I am on a course next week, but will be working evenings, and should be able to get this done by the end of the week.
I think there needs to be a "gentleman's agreement" between UI and Update on these properties. By putting these in a public UI interface, we are spelling out what the UI expects. Update and other product/bundleGroup providers will need to supply these, but probably won't have UI as a prerequisite.
*handshake* :-) Jeff, currently, there is no relationship between IProduct and IBundleGroup, and while IProduct is contributed as an extension, the IBundleGroup is registered with the platform (so the assumption is that the class that registers had been active before the UI asks for bundle groups). Will this change by end of 3.0 or will it stay as is?
The following is my current list of values in the ui's AboutInfo and where I think they can come from in the new scheme. The sources are a combination of specific methods in the IProduct and IBundleGroup and generic constants accessed through the keys I'm defining now. I wanted to give people a chance to comment on the mappings before I attach the patch. featureId IBundleGroup.getIdentifier versionId IBundleGroup.getVersion featurePluginLabel IBundleGroup.getName - I'm not positive on this one. Right now this value winds up coming from PluginDescriptor.getLabel, who's comment says "Returns a displayable label for this plug-in. Returns the empty string if no label for this plug-in is specified in the plug-in manifest file. Note that any translation specified in the plug-in manifest file is automatically applied." While the comment for IBundleGroup.getName says "Returns the human-readable name of this bundle group. " These seem to be describing the same thing -- is that just a coincidence? providerName IBundleGroup.getProviderName appName IProductConstants.APP_NAME_KEY windowImage IProductConstants.WINDOW_IMAGES_KEY <-- now an array aboutImage IProductConstants.ABOUT_IMAGE_KEY featureImage IBundleGroupConstants.FEATURE_IMAGE_KEY aboutText IProductConstants.ABOUT_TEXT_KEY welcomePageURL IBundleGroupConstants.WELCOME_URL_KEY welcomePerspective IBundleGroupConstants.WELCOME_PERSPECTIVE_ID_KEY tipsAndTricksHref IBundleGroupConstants.TIPS_AND_TRICKS_KEY Does this seem appropriate?
We need to also agree on the expected property values for things like windowImage, featureImage, *Image, or welcomePageURL.
For starters, the comments in org.eclipse.platform/about.ini should be incorporated into the Javadoc specs for these new constants.
Created attachment 8361 [details] defines two new interfaces to hold the constants This patch defines the constants I described in comment#8. I combined the text from about.ini with existing javadoc to describe each constant. Its still a bit vague on the type of each value.
Reminder: be sure to tag all new API elements introduced in 3.0 with "@since 3.0". For new classes or interfaces, tagging the class or interface is sufficient.
Created attachment 8364 [details] new patch with @since tags added changes from comment#12
Comment on attachment 8361 [details] defines two new interfaces to hold the constants new patch attached
Having the optoin for someone else to contribute branding is intersting. IProductProvider gives one that ability. So i don't think we need any additional ability to programatically spec products or product values. The workbench should be free to fetch these values however they like but keep in mind that we are putting forward this notion of "product" and people might use -product etc on the command line. To then get the branding from somewhere else might be confusing.
Regarding IBundleGroup.getName(), is this translated? I assume so since the bundle group provider is a regular extension and can translate strings. If not, this is a difference from what we had before.
I expect it to be translated.
I'm wondering about the content of the url's give in, for example, the IBundleGroupConstants.TIPS_AND_TRICKS_URL property. Should url given by the application have enough context to identify the bundle that contains the file or will there be enough information elsewhere?
Re comment #15, OK, I'll change the Workench to just use IProduct.
Created attachment 8410 [details] patch This patch removes the "_TAG" portion of the constant names and puts a "_URL" suffix on constants which expect an URL. An outstanding issue is to enhance the javadoc describing the URLs.
Re comment #20, we need to know who is responsible for resolving the URL for images, and also for resolving $nl$ variables (e.g. for the welcomePage property). Is it the bundle group provider or the Workbench? Both of these must be done in the context of the bundle group's primary plugin (plus any fragments), but it does not seem possible to determine the primary plugin from IBundleGroup. Can we assume that IBundleGroup.getIdentifier() can be used as the id for its primary plugin? Probably not since the feature story allows it to be different.
Previous comment should have read "Re comment #18". Note that TIPS_AND_TRICKS_URL has been renamed to TIPS_AND_TRICKS_HREF (same as about.ini) and is already resolved.
Patch applied with some minor changes, which I'll go over with Andrew.
The url format should be done either as absolute paths or as platform specific urls such as platform:/base/plugins/some_plugin_id/windowImage.gif in which case you won't have to worry about primary plugin id being different than primary feature id. For example, the update bundle group provider will read the about.ini and return append it to platform:/base/plugins/primary_plugin_id/.
Thanks for clarifying, Dorian. Returning a URL that is result of IPluginDescriptor.find is OK. Will you also resolve the $nl$ variable and friends? The constant definitions have been released to head in org.eclipse.ui.branding.IProductConstants and IBundleGroupConstants (in the org.eclipse.ui.workbench plugin). They did not make it into our integration build submission today, however since you're not going to be referencing them directly anyway, I guess it doesn't matter. Can you have a look over these and let us know if anything is unclear? Please check out what's in head rather than in the patches above.
Dorian, please let us know when Update starts providing the values so that we can make progress on bug 54547 (name, appName, windowImage, windowImages needed for M8) and bug 54548 (the remaining IProduct and IBundleGroup values needed for M9). The former is also blocking us from getting off the runtime compatibility plugin which we want to do for M8. Thanks, Nick
Nick, I will try to do it tomorrow so we have it done by next integration build. I figured the simplest implementation is to take the existing AboutInfo class and modify it. As alluded to in an earlier comment, the return values for windowImage/featureImage would be URL's (unless you want String values), and Images must be created by the UI component. The reason is that the code that returns the values runs in non-ui plugins.
The getProperty methods on IProduct and IBundleGroup only return Strings, so you'll have to return the (qualified, not partial) URLs in string form. We'll create the images from those.
Mea culpa... Once I started implementing it, I realized getProperty() returns String, not Object. I will probably have something for tonight's build, but I'll let you know.
Closing, since the constants have been defined, and Update is now generating them (bug 54574). Further changes to use IProduct are blocked by bug 54790.
