Community
Participate
Working Groups
Requirement: We need to show decoration (error/warning) on Tabs of Tabbed Property Views so that users won't have to go through all tabs in a view to find errors. I copied the following from the original request opened by Edmond (edmond_wang@ca.ibm.com) on another bugzilla: User Case 1: Add marker beside tab label 1. Got Error Marker from Resource ( will be done in our code) 2. Identify which section would be associated with that error ( will be done in our code) 3. From section, retrieve the Tab which contain that section (need help from 3.3) 4. Add Error icon besides tab label (need help from 3.3) User Case 2: Remove marker beside tab label 1. Got Marker remove event from Resource ( will be done in our code) 2. Identify which section would be associated with that error ( will be done in our code) 3. From section, retrieve the Tab which contain that section (need help from 3.3) 4. Remove Error icon besides tab label (need help from 3.3)
Created attachment 63420 [details] Error and warning icons on tabs and properties view header icon decorated An error or warning icon can be displayed on the tab (with the icon reflecting the most severe error encountered on the page. 1. this error/warning icon can be a decorator, meaning an overlay on the existing tab icon. If displaying multiple icons on the tab is an issue: 2. the error/warning icon can replace the tab icon 3. properties view header title should reflect the mostsevere error encountered in the properties.
Susan, right now you can drop a control decoration on top of any SWT control. What more is required for attaching them to property page tabs?
I'm not sure ControlDecoration should be used here. Since there is already a way to add an icon to the tab, and we are simply replacing the icon with an error indicator (as shown in the attachment), then I would suggest using whatever the existing mechanism is.
Susan, yesterday it wasn't clear to me if ControlDecoration could be used here. If it can be used, I believe it should be a valid option to teams to choose to decorate an existing tab icon, rather then replacing it. Aside my personal preference to decorate an icon, rather then replacing it with an error or warning icon. Of course the decoration needs to be large enough to not look like dirt on a screen ;)
Andree, ControlDecoration's purpose is to paint a decoration adjacent to a control in one of six positions (such as "draw a decoration to the top and left of this control"). There are no promises with respect to overlays or the order of decoration painting if multiple decorations are placed in the same location. So I don't think it's the tool to use for overlays. If we are talking about a 3.3 solution, then the simplest thing is to replace the graphic.
I agree, ControlDecoration is probably not an option here. Providing an API to change the image on the Tab would work. JFace's CompositeImageDescriptor can help, an example being Package Explorer in eclipse which uses Composite images to decorate already existing images for TreeItems.
Note API change for difficult for 3.3 at this point, it requires entire PMC approval (can happen but needs to be pretty high priority).
*** Bug 149052 has been marked as a duplicate of this bug. ***
In plan for Eclipse 3.4. Currently, the API for the tabbed properties view allows the active tab to have an image. The image is static. A new API is required to toggle the behavior to allow the image to appear on any tab. Additional API is required to change the image, either to replace with a new image (a decorated image) or to remove it.
Did anything happen on this?
This feature was on an IBM internal list for 3.4. No further follow up occurred since July 2007.
It is still something we would like to see happening.
Removing plan keyword for bugs that are not linked to the 3.5 (Galileo) plan.
This enhancement is targeted for the 3.5 release, but is not in the rolled up plan for the platform for 3.5 (plan keyword has been removed). I am guessing that there are too many enhancements from the 17 or so platform components, so the list is cleaned a little to list only major enhancements.
Moving target as M4 has shipped.
Removing target milestone as M6 has shipped a while ago. Note that we are well past the API freeze for 3.5 - this will have to wait until 3.6 (if still in plan).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
