Community
Participate
Working Groups
The first few lines of Workbench.createDisplay() are: // setup the application name used by SWT to lookup resources on some // platforms String applicationName = WorkbenchPlugin.getDefault().getAppName(); if (applicationName != null) { Display.setAppName(applicationName); } In fact, the application name - and now the application version - are also being used by screen readers. These strings are used to announce the name and version of the application, and they are used to determine any special handling that may be needed for that application and version. There is a new API on Display called setAppVersion(String). The string should be "3.6" (or "3.6.0") for Eclipse 3.6, and "3.6.1", etc. for maintenance builds. Do not use "3.6M7" or "3.6RC1". (The crash in Bug 311434 would not have happened if this had been set).
John, Kim, any idea what would be good to set to the version? Does the product that's currently running come with a matching version number? PW
The product files specify 3.6.0.@qualifier@ now, where @qualifier@ is replaced by the build id at build time. Not sure if this answers your question...
Susan, from your time in About land, do you have a good candidate for a product version number? Not enough info: eclipse.buildId=I20100513-1500 Probably wrong guy to ask: osgi.framework.version=3.6.0.v20100512 from scanning the org.eclipse.sdk plugin, there's nothing in the product specifically and the plugin.properties defines 3.6.0 in productBlurb directly. PW
I think that the screen reader developers would be ok with "3.6.0.v20100512" (if you decide that it is ok to ask the osgi framework for the version number... or if you find that same value in a more logical place). They are looking for something that can be easily collated and logically compared to the previous version, and I think that even with the 'v' in there, they would probably be ok. And I think the user would not mind having the extra info spoken. And since it is actually a very precise version number, that may be useful somewhere down the road.
The framework version isn't too helpful since it doesn't say much about the product you are running. My suggestion is something like: name = Platform.getProduct().getName() ver = Platform.getProduct().getDefiningBundle().getVersion() If you want only three parts for the version number you could do something like this afterward: ver = new Version(ver.getMajor(), ver.getMinor(), ver.getMicro(), null)
Created attachment 168807 [details] Set version v01 With this option I'll get a version like: 3.6.0.v201005131500 or the empty version 0.0.0 PW
You need a null check on the result of Platform.getProduct().
Platform.getProduct() can return null, can you please add a null check? Also, if there is no product, wouldn't it be better to default to something like the version of the RCP feature, or the version of the org.eclipse.ui bundle rather than 0.0.0?
Created attachment 168901 [details] Set version v02 New version of the patch. Uses the same pattern as getAppName() and adds the null protection. re: a default version If we don't have a product, I don't think we can return a useful answer re: what version am I running, and I think that 0.0.0 is appropriate. If that's not sufficient and we want something other than 0.0.0 I'd suggest the org.eclipse.ui.workbench bundle version. At least you would have a concrete thing that is running (the workbench). PW
Created attachment 168955 [details] Set version v03 Same as version 2, but if we can't find a product plugin we use the version for org.eclipse.ui. If we can't find that, *then* we return the empty string "0.0.0" Boris and John, could you please review. PW
Released for I20100520-0800 PW
My browser killed the flags. John, Boris, could you please reset them. I'd do it myself, except then it would look like I give myself +2 :-) PW
Verified in I20100520-1744 Carolyn, it's set to 3.6.0.v201005201744 Does that produce the kind of output you/they expect? PW
.
At the moment, they are not parsing the string. They just want a string that makes some sense when spoken to a user. The current one fits the bill well enough. If/when they need to parse the string, if they decide that they prefer 3.6.0, then I will strip off the extra .v... before I send it to them. I have spoken to some folks about fully specifying the version string (at present, the spec for IAccessibleApplication::appVersion is too vague). They are still mulling it over <g>. Thanks!
