Community
Participate
Working Groups
PDE should provide some indication whether extension elements are deprecated. For example, org.eclipse.ui.menus provides <menuContribution> as well as the now-deprecated <group> and <widget> elements.
Contribution pushed to Gerrit: https://git.eclipse.org/r/22739
Initial review: - No copyright updates - No copyright header or basic javadoc on the decorator class - Using a decorator with its own image registry is a different pattern than used elsewhere. If it were moved to PDELabelProvider the warning overlay would be shown anywhere we used the schema element in the future. - No indication to the user why the overlay is there. When selected, the right hand side doesn't say it is deprecated. The plugin.xml will have a warning marker if the project settings include the deprecation check. Even a tooltip hover would give some opportunity for the user to guess
I certainly like the "(deprecated)" appended to the context menu entries. The icon overlay I don't think is as helpful with no explanation. The icons could also be associated with the deprecated marker error level.
Thanks Curtis. I've pushed up a revised change that backs out the label provider and an unrelated change that snuck in there. Bringing in the warning into the PDELabelProvider isn't as straightforward. The ExtensionsSection uses a custom label provider and doesn't delegate to the PDELabelProvider. So I'll leave that for now.
(In reply to Brian de Alwis from comment #4) > Bringing in the warning into the PDELabelProvider isn't as straightforward. > The ExtensionsSection uses a custom label provider and doesn't delegate to > the PDELabelProvider. So I'll leave that for now. If the section has its own label provider, then the decorator approach is more reasonable. My concern about the icons having no explanation for the user still stands.
(In reply to Curtis Windatt from comment #5) > If the section has its own label provider, then the decorator approach is > more reasonable. My concern about the icons having no explanation for the > user still stands. I don't disagree. The (deprecated) marker at least ensures people don't accidentally create new instances deprecated elements. I've taken a stab at propagating the deprecation warning and indicators into the extensions page with the following patch: https://git.eclipse.org/r/24345 It puts warning markers on deprecated elements or elements containing deprecated attributes. On the right-hand side of the extensions page, it adds a "(!)" marker to the labels for deprecated attributes and adds a "This attribute is deprecated" warning in the hover help. It also adds helper text to the section headings to indicate that an element is deprecated. Non-deprecated elements are sorted above deprecated attributes.
Created attachment 241525 [details] Small test project with deprecated elements This attachment has a small project with three different types of elements: 1. elementWithDeprecatedAttribute: a non-deprecated element with a deprecated attribute. This element should only show a warning if the deprecatedAttribute actually has a value. 2. deprecatedElementAndAttribute: should always be marked with a warning. 3. deprecatedElementOnly: has no attributes, but is itself deprecated and should always be marked with a warning.
Created attachment 241526 [details] Screenshot showing the deprecation markers Note that the elementWithDeprecatedAttribute is not marked with a warning since its deprecated attribute has no actual value.
http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=4601464e73e5b534bd6482db8afb62a850c7ec37 http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=8a2d81ebcd145f072c835f3b85a02a7342478c6a Brian's work pushed to master http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=e0f7dd702c357cb9bfde3b3a2be36a5adba7194c My additional changes I made some additional tweaks, deprecated attributes are no longer removed from the normal order (still are marked with (!). I made a number of changes to support proper NLS (though there are likely a number of places in the editor we still fail with RTL locales). The one piece that I would still like to see is having the warning icons in the tree correlate with the project/workspace preference setting. By default deprecations are warnings, so the warning icon overlay is correct. However, switching to error/ignore may cause some confusion. Since the icons are only visible when driling down to a specific element, what we have is good for now.
Verified in I20140428-2000.
I'm seeing a regression caused by http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=8a2d81ebcd145f072c835f3b85a02a7342478c6a Please see the change in ExtensionsSection.resolveObjectImage() resulting in: IPluginElement element = (IPluginElement) obj; Image customImage = getCustomImage(element); if (customImage != null) elementImage = customImage; customImage = PDEPlugin.getDefault().getLabelProvider().getImage(obj); if (customImage != null) elementImage = customImage; The final assignment to elementImage discards the result from getCustomImage() which IMO is wrong, since we are using a useless default icon to replace a specific custom image: I'm seeing DESC_GENERIC_XML_OBJ all over the place where I used to see specific icons. BTW: I'm using a custom image _provided by the extension_ as a clumsy workaround for bug 195764 (would like to show icons provided by the _extension point_).
Another regression caused by the same http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=8a2d81ebcd145f072c835f3b85a02a7342478c6a The change in ExtensionElementDetails.updateDescription() throws NPE in line 256. Please consider ExtensionPage.java:100 to see that null is a legal value for the field schemaElement!
The NPE is already fixed in 4.5 with bug 435872. I'll backport that to 4.4.1 in a minute. Stephan, please open a new bugs for the icon (with steps if possible), make it depend on this one and cc me please Thanks.
