Community
Participate
Working Groups
I need this in my plugin (decorators) because: For instance there are 2 classes: p1.p2.c1 p1.p2.p3.c2 class c2 has TODO tag. in hierarchical mode packages p1, p2, and class c1 should be decorated. in flat mode we have 2 lines (exactly as shown in 'For instance there are 2 classes') but packages p1 and p2 will be decorated in both lines which isn't what I want. I need to decorate only line 2 as it is the only one which has TODO tag. Thank you.
If we would expose the 'is in hierarchical mode' on the IPackagesViewPart that wouldn't help you as decorators are not aware in which viewer they are decorating. We also have a second viewer that supports hiearchical packages in the browsing perspective. The solution for this would be, in my opinion, the new API suggested in bug 210076. There, the decorator will get access to a 'viewer 'resource mapping of the correct element. If you have a different suggestion, please let me know.
Yep. But this property is still need to me made public. All what's related to it is in internal package. Thank you!
Can you give more information how and why you need it? I just need some examples to see if this API really would be useful.
Not sure what kind of additional information you need. My decorator should behave differently in different presentation modes (flat or hierarchical) as described in my 1st post, so I need access to current view mode where I am decorating stuff.
Does your decorator know in which view it is decorating? Normally decorators are contributed as light weight decorators and the only thing they get is the element to decorate.
Now I couldn't tell which view I am decorating. I think decorators are only supported by package explorer. More information on plugin: http://www.krupets.com/fun/twiki/bin/view/TODODecorator
I found a way to check whether it's flat or not. But it is a hack (if you say decoration can take place in different views). HierarchicalDecorationContext is used when view is hierarchical otherwise DecorationContext.DEFAULT_CONTEXT is used. Another problem is that HierarchicalDecorationContext is in internal package.
As you are a lightweight label decorator contributor, your plug-in decorates Java elements in all views. Have a look for example at the browsing perspective. There can also be several instances of package explorers (in multiple windows). The 'HierarchicalDecorationContext' is the right way to go. And my request to platform UI in bug 210076 would make that functionality available through API.
Ok. In 3.4 even HierarchicalDecorationContext isn't working any more. Now flat/hierarchical state is totally private. Thanks.
