Community
Participate
Working Groups
I like the decorator concept and have added a decorator extension. The decoration in my code is expensive requiring a series of database queries and file accesses. I can currently decorate the image and text like I want. While I have that status information in the decorator code, I would like to be able to modify the tooltip to tell the user how to address the specific status issue (if one exists) for that object. for example: ILabelDecorator public String decorateToolTip(String tooltip) IDecoration decoration.addToolTipPrefix(String prefix) decoration.addToolTipSuffix(String suffix) decoration.addToolTipOverlay(ImageDescriptor ImageOverlay) I think this would be better than a) persisting the status in the decorator code or my object b) Getting access to the decorator text, deciphering it, and modifying the tooltip through the label provider. Maybe there is another way to do this that I'm not aware of.
An item can have four decorators on its type icon, and as you know each is quite small (8x8). Thus each is an extremely small item for a user to hover over with their mouse, and it'd be easy to get the wrong one. Similarly, with the text only decorators, they can be quite short, and it might be difficult for the user hover v.s. the main text (even if they thought to, which they likely wouldn't). Another approach is to combine all the tooltips for all the decorations together. But if multiple contribute tooltips, how would we manage this? You'd get a really long concatenated string. I like the idea of providing feedback to the user on the purpose of the decorator but not sure how to manage the display of that information. Did you have something in mind?
I think John's problem is that he doesn't want to store duplicate information. He is doing the decoration and restores the status information inside his ILabelDecorator. I think the only thing he is requesting is that the proposed CellLabelProvider subclass in bug #182216 is delegating calls to the ILabelDecorator. Something like this: -------------8<------------- public class DecoratingCellLabelProvider { public String getToolTipText(Object element) { String text = provider.getText(element); String decoratedText = ((ILabelDecorator2)decorator).getToolTipText(text,element); if( decoratedText != null ) { return decoratedText; } return text; } } -------------8<-------------
(In reply to comment #1) > An item can have four decorators on its type icon, and as you know each is > quite small (8x8). Thus each is an extremely small item for a user to hover > over with their mouse, and it'd be easy to get the wrong one. > Similarly, with the text only decorators, they can be quite short, and it might > be difficult for the user hover v.s. the main text (even if they thought to, > which they likely wouldn't). > Another approach is to combine all the tooltips for all the decorations > together. But if multiple contribute tooltips, how would we manage this? > You'd get a really long concatenated string. > I like the idea of providing feedback to the user on the purpose of the > decorator but not sure how to manage the display of that information. > Did you have something in mind? I agree that trying to get a tooltip per 8x8 pixel decoration doesn't make sense. I was thinking that the hover help decorators would all contribute to the same tooltip ... just as the text decorators do. Which brings up your next point ... don't we get a long message? In the decorate method of an ILightweightLabelDecorator, is this currently a problem with the current IDecoration.addPrefix(String prefix) and IDecoration.addSuffix(String suffix)? It seemed like a decorator could just add a new line character to make the tooltip text more readable. It seems like hover help for the Java editor can give some pretty long messages, but you can select F2 and read it with the scrollbar. This seems like a pretty good solution.
Oleg is now responsible for watching the [Decorators] category.
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.
