Community
Participate
Working Groups
I have a custom editor that validates its contents and produces Problem markers on the resource when it finds problems. Problem markers show up in the editor's vertical ruler, the Problems view, and the Project Explorer resource nodes. The problem icon decorators in the Project Explorer are displayed when my plug-in is installed under Eclipse SDK distribution. But, when I install the plug-in under Eclipse Platform Runtime Binary distribution, the problem icon decorators do not display in the Project Explorer. Project Explorer is the default resource navigator for the Resource Perspective. I would like to get the same behavior with problem icon decorators under the Platform IDE, as I do with the SDK. I do not know if this is a bug, or a missing implementation on my part. I have asked this in the Platform forum and have not had a response either way. Please advise. Thanks. Amir
Probably related to bug 262415
I would say that it also appears with a different RCP app on Mac OSX. For me there is the situation that I have several validators adding markers. When I disable one in particular the markers do show. Maybe there is some uncaught and UNLOGGED exception that makes the marker decoration abort early...
(In reply to comment #0) > But, when I install the plug-in under Eclipse Platform Runtime Binary > distribution, the problem icon decorators do not display in the Project > Explorer. I ran into the same problem recently. According to some google research I found a workaround: Add org.eclipse.jdt.ui plugin to your RCP and magically the problem markers get visible. As some of us might not need JAVA support in our custom RCP app, it would be fine to move the necessary code from jdt.ui to the core bundle where the project explorer is located.
Note that the PE without JDT extension works like the Resource Navigator, which does not support problem marker decoration. JDT is not part of the Platform Runtime environment and therefore you don't get the decorators. JDT is part of the SDK, though, that's why you see the decorators there.
(In reply to comment #4) > Note that the PE without JDT extension works like the Resource Navigator, which > does not support problem marker decoration. Why does the project explorer natively not support problem markers? I guess there is not only java that needs those markers. So I propose to add marker support to the platform runtime to have it available even without JDT.
*** Bug 268839 has been marked as a duplicate of this bug. ***
See the partial patch in bug 268839 as well as the comments that this needs to be handled by the CNF. This is really an enhancement request in my view, as far as I know the CNF was not designed to deal with these decorators from the beginning. It's also not clear if this should be the CNF itself or the ProjectExplorer. Certainly if working sets to are to be involved, then it would be ProjectExplorer (since the CNF does not know anything about working sets. On the other hand, there is some argument that the CNF should handle working sets more directly.
> So I propose to add marker support to the platform runtime to have it available > even without JDT. I agree with you, and if you would like to working on this I would be happy to help. Right now I don't have a lot of time to spend on the CNF.
I(In reply to comment #7) > This is really an enhancement request in my view, as far as I know the CNF was > not designed to deal with these decorators from the beginning. Which is a bug ;-)
I used to have a Windows XP computer, and never encountered this problem (Error marks not showing in Navigator, but errors marks can be seen in Package Explorer). A week ago, switched to Windows 7, and error marks are not shown in Navigator. Don't know if this observation useful in solving this bug, thanks.
(In reply to comment #10) > I used to have a Windows XP computer, and never encountered this problem (Error > marks not showing in Navigator, but errors marks can be seen in Package > Explorer). A week ago, switched to Windows 7, and error marks are not shown in > Navigator. > Don't know if this observation useful in solving this bug, thanks. The 'Navigator' view never showed/shows error or warnings out of the box. Maybe you had some additional plug-in installed on Windows XP that did this.
Any progress in this? If its difficult to extract the decorator from JDT, could we add at least a new (explicit) decorator for markers that is disabled per default to avoid any side effects for the JDT, but may be enabled using preferenceCustomization for a specific product (which doesn't include the JDT)?
*** Bug 413082 has been marked as a duplicate of this bug. ***
The JS EPP package, which doesn't have JDT installed, reports problem to the Project Explorer. AFAIK, the C++ one does too.
This is very simple to reproduce: Take whatever IDE, which reports problem markers on Project Explorer. Create a problem, and see the problem marker on Project Explorer. Go in Project Explorer view menu > Customize View... (or Filters and cusotmization... iwith Oxygen) > tab "Content". Deselect content coming from JDT, JSDT, CDT... The problem marker disappeared. The reason seems to be that the Problem decorator is contributed by those CNF providers. However, Problems are language-indepedent. So a solution would be to create a specific extension for problems in Project Explorator (let's name it "Problem markers decoration") and to enable it by default. People who don't want it would have the opportunity to remove it by going to the "Filters and Cusotmization... > Content" and unticking the "Problem marker decoration" checkbox. Thoughts?
I'll copy and adapt "ProblemLabelDecorator" from EGit. @Robin: as the author of this class, do you have any objection or concern?
(In reply to Mickael Istria from comment #16) > I'll copy and adapt "ProblemLabelDecorator" from EGit. > @Robin: as the author of this class, do you have any objection or concern? No I don't, go ahead :).
Thanks Robin. I'm taking this one and targeting it for 4.7.M3 as I think it's an important issue in Platform's 4.7 theme "simplify new languages support".
New Gerrit change created: https://git.eclipse.org/r/82357
Gerrit change https://git.eclipse.org/r/82357 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=6129ab33ff77e3545bf403906dc1604b61e9d18c
There is now a decoration provider (via the Decoration preference page) for Problems on IResources.
New Gerrit change created: https://git.eclipse.org/r/82839
Gerrit change https://git.eclipse.org/r/82839 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0feaf5a57025f70a746076cf160cc8060e40f932
@Dani: what's the issue?
(In reply to Mickael Istria from comment #21) > There is now a decoration provider (via the Decoration preference page) for > Problems on IResources. This is a no go and I had to revert it. You can't enable the decorator on generic elements, be it 'Object or 'IResource'. This can only be done per view. Views that already decorate problems now do it twice - unacceptable performance hit. Views can also decide to not show problems on their elements or do it differently. There are tons of errors logged for closed projects and this also writes to the console (see bug 505644). It looks like code got copied (comment 16), but the original author is not listed in the Gerrit change and that author has no valid ECA. Just a comment from the author in bugzilla is not enough.
(In reply to Dani Megert from comment #25) > You can't enable the decorator on generic elements, be it 'Object or > 'IResource'. This can only be done per view. Views that already decorate > problems now do it twice - unacceptable performance hit. > Views can also > decide to not show problems on their elements or do it differently. Here, I thought the grain and target of the requested functionality was the same as team decorators. EGit binds decorator on all view that allow it (as far as I understood), and no one complained as far as I know. The performance hit is very acceptable in term of user perspective. As I experienced it, it's far from being a blocker IMHO, it's not even noticed. Also, I'm curious about it. How can a view that allows Git decorators be annoyed by problems report? > There are tons of errors logged for closed projects This was definitely a bug in the proposed patch. > It looks like code got copied (comment 16), but the original author is not > listed in the Gerrit change and that author has no valid ECA. Just a comment > from the author in bugzilla is not enough. Ok, thanks for the hint. @Robin: Can you please sign the ECA ?
(In reply to Mickael Istria from comment #26) > (In reply to Dani Megert from comment #25) > > You can't enable the decorator on generic elements, be it 'Object or > > 'IResource'. This can only be done per view. Views that already decorate > > problems now do it twice - unacceptable performance hit. > > Views can also > > decide to not show problems on their elements or do it differently. > > The performance hit is very acceptable in term of user perspective. As I > experienced it, it's far from being a blocker IMHO, it's not even noticed. No, it is not acceptable to do something twice. It not only slows down problem marker decoration but other decorations that are done in the same thread. It is a blocker. The second thing, that a view might not want to have them and spoil them with problem decorators is also a blocker. > Also, I'm curious about it. How can a view that allows Git decorators be > annoyed by problems report? Because you only use one UI plug-in for EGit, this works.
So it means that the solution should be specific to Project Explorer only? As JDT/CDT/JSDT contribute error report to Project Explorer, so in any case, the fact that JDT/CDT/JSDT already does it makes that decoration will most likely happen twice. Does that mean that we'll never be able to fix this issue because other plugins already do it (at the wrong place of the IDE)?
(In reply to Mickael Istria from comment #28) > So it means that the solution should be specific to Project Explorer only? > > As JDT/CDT/JSDT contribute error report to Project Explorer, so in any case, > the fact that JDT/CDT/JSDT already does it makes that decoration will most > likely happen twice. Does that mean that we'll never be able to fix this > issue because other plugins already do it (at the wrong place of the IDE)? Even the Project Explorer can do it for most cases. You are trying to fix a corner case where the specific content extensions, like 'Java Elements' are disabled or not there. And "no", it's not done at the wrong place because the Platform does not know how to decorate a Java field or a CDT element. So, it should be implemented inside the Project Explorer for only the cases mentioned above.
(In reply to Dani Megert from comment #29) > You are trying to fix a > corner case where the specific content extensions, like 'Java Elements' are > disabled or not there. I'm quite disappointed by this answer. Seems like I failed at sharing my vision and goals for the Eclipse IDE and all the work related to Platform's 4.7 theme "simplify new languages support". Here is the user story: as an Eclipse plug-in developer, I want to create an Eclipse-based C# IDE (actually, more something like "Eclipse IDE for .NET Developers") with all the state-of-art usability of an IDE, with the lowest amount of effort. If we focus on this user story, I read your answer as "please install JDT into your C# IDE if you want error report on resources". It's not an acceptable answer. Another answer would be "Please implement your own content provider to put markers on *.cs files", which is basically what JDT, JSDT, CDT are already duplicating. If we focus only on cases where JDT is present, then Eclipse Platform is missing its own goal and is failing at delivering the expected value of being an efficient platform to develop IDEs (and RCP apps). Eclipse can live without JDT, the Platform should be designed gathering requirements from JDT, not relying on it to provide solutions to common problems. The IDE should have as much features as possible to enrich user experience without a need for language tools. The problem markers on resources are a very interesting one. With this patch, I could have my .cs, .json or whatever files showing a red cross in Project Explorer without any specific contribution to Project Explorer. It was a very pleasant thing. > And "no", it's not done at the wrong place because > the Platform does not know how to decorate a Java field or a CDT element. The Platform knows how to decorate whatever IResource according to Problem markers, there is no need for more semantic here. I'd like to propose a trade-off: what about having this decorator listed, but off by default? At least, packages that will like to use it in some future could, without high cost of development.
(In reply to Mickael Istria from comment #30) > The IDE should have as much features as possible to enrich user experience > without a need for language tools. The problem markers on resources are a > very interesting one. Sure, but not at the cost of breaking things and slowing down performance. > > And "no", it's not done at the wrong place because > > the Platform does not know how to decorate a Java field or a CDT element. > > The Platform knows how to decorate whatever IResource according to Problem > markers, there is no need for more semantic here. Yes there is, because you can't know how to decorate Java fields for example. That's why the decoration and the content belong together. Here's one way to fix this: 1. You only enable this on resources where no content provider is registered. 2. You add a new implict attribute to the 'org.eclipse.ui.navigator.navigatorContent' extension point, where one can specify that the generic problem decoration should be used (false by default).
(In reply to Mickael Istria from comment #30) > Seems like I failed at sharing my vision and goals for the Eclipse IDE and > all the work related to Platform's 4.7 theme "simplify new languages > support". There are much more use cases as "simplify new languages support". One of the use case is that the products require a highly scalable IDE. I don't want to have decorators to run twice or more time for displaying same markers on our projects. What is "acceptable" for small projects doesn't scale for 100.000 files. I have not checked API, but is this possible to know if the JDT (or any) decorator was configured to the navigator and run the "generic" decorator only if there were no other decorators contributed/enabled? Also can we try to eliminate default problem decorations for files/folders from existing decorator contributions in CDT/JDT/you name it for 4.7 and document that this will be done by the framework "by default"?
Ok, thanks for your insights, all. I believe this discussion is fruitful as it makes me consider simpler approaches. I've something else in mind to try, but it would be nice if I could get your opinion on it before starting to actually code it. Can I simply add the marker decoration in the ResourceExtensionLabelProvider? I believe it would do what I'd like (decorate resources when none of JDT/JSDT/CDT is there) and would not apply to content provided by other CNF extensions than the Resourses one. WDYT?
(In reply to Mickael Istria from comment #33) > Can I simply add the marker decoration in the > ResourceExtensionLabelProvider? I believe it would do what I'd like > (decorate resources when none of JDT/JSDT/CDT is there) and would not apply > to content provided by other CNF extensions than the Resourses one. WDYT? I must confess I don't know the CNF API enough to suggest here anything but looking at the code it seems to be the best fit. Please note, that this one can be disabled by user in same way as the rest of CNF contributions!
(In reply to Mickael Istria from comment #33) > Ok, thanks for your insights, all. I believe this discussion is fruitful as > it makes me consider simpler approaches. I've something else in mind to try, > but it would be nice if I could get your opinion on it before starting to > actually code it. > Can I simply add the marker decoration in the > ResourceExtensionLabelProvider? I believe it would do what I'd like > (decorate resources when none of JDT/JSDT/CDT is there) and would not apply > to content provided by other CNF extensions than the Resourses one. WDYT? This is a very good step into the right direction, as it no longer pollutes other views, but it still has the problem of duplicate decoration as long as other extensions are enabled. You still have to follow my advice from comment 31. (In reply to Andrey Loskutov from comment #34) > Please note, that this one > can be disabled by user in same way as the rest of CNF contributions! Yes, but if you disable the resource extension, no resource will be shown ;-).
(In reply to Dani Megert from comment #35) > This is a very good step into the right direction, as it no longer pollutes > other views, ok, cool. > but it still has the problem of duplicate decoration as long as > other extensions are enabled. You still have to follow my advice from > comment 31. I'm a bit confused here. In a previous comment you say "the decoration and the content belong together.". Doesn't it apply to CNF? Ie doesn't a label provider apply only to elements that were contributed by the content provider of the same extension? If it only applies to the elements provided by related content provider, then it seems like JDT won't decorate resources.
(In reply to Mickael Istria from comment #36) > > but it still has the problem of duplicate decoration as long as > > other extensions are enabled. You still have to follow my advice from > > comment 31. > > I'm a bit confused here. In a previous comment you say "the decoration and > the content belong together.". Doesn't it apply to CNF? Ie doesn't a label > provider apply only to elements that were contributed by the content > provider of the same extension? > If it only applies to the elements provided by related content provider, > then it seems like JDT won't decorate resources. You're right! :-)
New Gerrit change created: https://git.eclipse.org/r/82899
Delayed.
Gerrit change https://git.eclipse.org/r/82899 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5e278030c6d0836ae2f195ad8bb0ecdff263265f
Verified in I20170411-2000.
