Community
Participate
Working Groups
Build ID: M20071023-1652 Steps To Reproduce: When there's a build path problem that prevents a project from being built, I think that Eclipse doesn't highlight the problem enough. After almost three years of working every day with Eclipse, it happens, from time to time, that some co-workers of mine ask me why some strange behaviour occurs... behaviours that often take some minutes to make me realize that they're due to build path problems on one of the projects in the dependency chain... It may often happen that a project of youers has some code that doesn't compile, but you don't bother because you actually don't need that code at a certain point. But then, the white small "X" on red background on the icon of the project doesn't tell you enough information if there's also a build path problem. If you don't open the "Problems" view, or if this view is hidden, you won't be able to find out when a build path problem is affecting your project or one of those it depends on (missing library, missing required project, missing code indirectly needed by a JAR in the build path, file system permissions problems and so on...). So, my request is this: it would help a lot if Eclipse could mark a project in some way (maybe with a new icon or a new symbol over the existing icon) when that project has any build path problem that prevents it from being built.
Moving to JDT/UI
Martin, I also ran into this. A fix might be quite easy.
Could try to simply use a bigger problem icon.
Deepak, could you please do some experiments with a bigger icon? For now, just take e.g. org.eclipse.jdt.ui/icons/full/obj16/error_obj.gif and shrink it a bit, so that it looks bigger than the normal error overlay, but still keeps the project icon and the "J" visible. If the experiment looks promising, we can request final icons from the designers.
JSP page always reports the "error": String literal is not properly closed by a double-quote. But in fact they are not error . Sometimes restart the eclipse ,then they donot appeare. They always happen about the jspscriptlet.
(In reply to comment #5) That's not related to this bug. Please open a new bug against the JSP plug-in you use (probably WebTools) and give precise steps to reproduce there.
Created attachment 163984 [details] screenshot Something like this? ONLY the project icon has a bigger error overlay in case of error in an IProject resource.
Created attachment 163985 [details] Patch to get the result in screenshot from last comment
IMHO the difference between the however bigger icon and the standard one, as seen on the posted screenshot, is not so evident. I mean, on a first look it's not easy to realize that project "error" has a greater "X" (that is: it has a build path error) while "_pasted_code_" has a smaller one (that is: it has just standard errors). Maybe a "!" mark beside the "X" and/or a different shape (I don't know, round instead of squared), in addition to the bigger size or not, could help more?
I agree with Mauro: the difference is hard to recognize. Other options: - add a (thicker) border instead of making the icon bigger - use a different icon, e.g. a red 'BP' - change the label color from black to red
Created attachment 164004 [details] screenshots Agree, the difference in hard to recognize. I am attaching screenshots of other options I tried. My favorites are the 1st and 3rd screenshots in the second row. I tried "!" mark as well as different shapes, but for such a small icon these do not help much. Also I would use a different icon than just changing the color (2nd and 3rd screenhots in the first row) as Wikipedia (http://en.wikipedia.org/wiki/Color_blindness) says about 8% people are color blind. > - use a different icon, e.g. a red 'BP' Dani, what is a 'BP' ?
>Dani, what is a 'BP' ? Letters B an P (like the J for Java). I like the version with the no entry sign.
I think BP stands for "Build Path". My favourites are 1st and 3rd of the second row, too, but personally I would make them bigger (like the first one of the first row). In this way, not only the icon would be different between a build path error and a standard one, but it should also be more evident (because it is actually a severe problem that leads to project not being built at all, as my original report highlights). In other words, what should be achieved here is the following: giving a quick look at the Package Explorer, the user should "immediately" note that a project has a build path problem, rather than containing other "standard" problems.
I agree, the variants in attachment 163985 [details] don't really jump into my eyes. We should only consider "BP" as a very last resort, if we really have no better idea. In contrast to the "J" for "Java", "BP" is not language neutral and is also not easily understood in English. > Maybe a "!" mark beside the "X" [..] could help more? That's a good idea. Deepak, can you try it with the "!" that's used in the Tasks view for high-priority tasks? That's /org.eclipse.ui.ide/icons/full/obj16/hprio_tsk.gif. Leave the error on the project as it was before, but overlay the big "!" centered (or try moving it around a few pixels if it overlaps important parts of the project icon or doesn't look good). Note: You should never include binary files (e.g. images) in a patch. This doesn't work reliably, and we even had cases where the patch could be applied but the image was slightly garbled in the end.
Created attachment 164025 [details] small "!" Another variant could be to _replace_ the error mark with a red "!". Here's a smaller version of hprio_tsk.gif that keeps the white border around the sign, so that it better stands out from the project icon. The problem with most of the variants from attachment 164004 [details] is that their shape is too similar to the existing error icon, so their difference is not easy to spot at a glance.
>Another variant could be to _replace_ the error mark with a red "!". +1
Created attachment 164039 [details] screenshot (In reply to comment #14) > > Maybe a "!" mark beside the "X" [..] could help more? > > That's a good idea. Deepak, can you try it with the "!" that's used in the > Tasks view for high-priority tasks? That's > /org.eclipse.ui.ide/icons/full/obj16/hprio_tsk.gif. Leave the error on the > project as it was before, but overlay the big "!" centered (or try moving it > around a few pixels if it overlaps important parts of the project icon or > doesn't look good). This was one of the first things I had tried, but the result was not good at all. The error icon is too small to try to overlay it with something. At least I could not do much here. >Another variant could be to _replace_ the error mark with a red "!". This looks promising! Attaching screenshot for this one in package explorer.
> The error icon is too small to try to overlay it with something. I didn't mean to center the "!" on the error icon. I meant it to be centered on the whole project icon. That would have the advantage that the well-known error icon is still there in case of build path errors. Could you please try that? > >Another variant could be to _replace_ the error mark with a red "!". > This looks promising! Attaching screenshot for this one in package explorer. No too bad. It we take that version, you should move the "!" down by 1px so that it aligns with the CVS silo (probably easiest to do by removing the white border at the bottom in the image file).
Created attachment 164194 [details] screenshots (In reply to comment #18) > > The error icon is too small to try to overlay it with something. > > I didn't mean to center the "!" on the error icon. I meant it to be centered on > the whole project icon. That would have the advantage that the well-known error > icon is still there in case of build path errors. Could you please try that? Attaching screenshots for this. There is not too much space to this as well, as there is a error icon on the bottom left and the cvs decorator on the bottom right. The case with the "!" next to "J" looks too cluttered to me. I think the error icon should be replaced - 2 problem indicators on one project icon may be confusing to the user. We can go with either a solo "!" (attachment 164039 [details] [diff]) or the circular fatal error icon (attachment 164004 [details] [diff] - 1st one on the 2nd row.)
>I think the error icon should be replaced Agree. We should replace it with a (big) red '!'.
Yep, 2 error indicators look too noisy. Please try these 2 variants (screenshots with CVS decorations): A) second part of comment 18 B) same as (A) but with the original big hprio_tsk.gif When you remove the white pixels at the bottom, make sure you keep the transparency in the image. All of the screenshots in attachment 164194 [details] are wrong, since they miss the transparent pixels on both sides between the "|" and the "." of the "!". Mspaint probably screws this since it doesn't support transparency. E.g. paint.net should work -- or ping me if I should send you the cut images.
Created attachment 164334 [details] screenshots for 2 variants (In reply to comment #21) > Yep, 2 error indicators look too noisy. Please try these 2 variants > (screenshots with CVS decorations): > A) second part of comment 18 > B) same as (A) but with the original big hprio_tsk.gif Variant B looks good - the bigger "!" and the error icon have about the same number of red pixels and hence appear equally evident. The smaller "!" looks quite small. > When you remove the white pixels at the bottom, make sure you keep the > transparency in the image. All of the screenshots in attachment 164194 [details] [diff] are > wrong, since they miss the transparent pixels on both sides between the "|" and > the "." of the "!". Mspaint probably screws this since it doesn't support > transparency. E.g. paint.net should work -- or ping me if I should send you the > cut images. Oops, did not notice this earlier, Paint.net does the job now. Thanks!
>Variant B looks good - the bigger "!" and the error icon have about the same >number of red pixels and hence appear equally evident. The smaller "!" looks >quite small. Agree. Filed bug 308608 to also use the same icon for the build path marker.
I also prefer the B variant.
After seeing bug #308608, I was wondering if the icon we're discussing here is planned to be used just in the Package Explorer or also in the Project Explorer? I think it should be better used in both views...
(In reply to comment #25) > After seeing bug #308608, I was wondering if the icon we're discussing here is > planned to be used just in the Package Explorer or also in the Project > Explorer? I think it should be better used in both views... Yes, it will be shown in both views.
(In reply to comment #22) Nice, please release (B).
Created attachment 164366 [details] fix Patch + icon released to HEAD. Markus, the original hprio_tsk.gif file is 206 bytes. After I crop this icon to fit our needs using Paint.net and save, it becomes 869 bytes. As discussed, please have a look.
.
Created attachment 164412 [details] additional fix (In reply to comment #28) I don't know why Paint.net makes the image use more disk space. I redid the cropping with Gimp and released to HEAD. When looking at the outcome, I realized that it's still hard to spot the build path problems in the Package Explorer when you have working sets as top level elements. Changed PackageExplorerProblemsDecorator to propagate the "!" to working sets. Since we're past the API freeze, I've removed the API addition in JavaElementImageDescriptor and opened bug 308672.
Verified in I20100425-2000 on Windows 7.
WTP is seeing some issues with this change because this new error marker is showing up for non build path errors; see bug 310551. Please reopen this bug and narrow the logic for showing '!' only for build path problems and not for any IProject error marker.
(In reply to comment #32) > WTP is seeing some issues with this change because this new error marker is > showing up for non build path errors; see bug 310551. Please reopen this bug > and narrow the logic for showing '!' only for build path problems and not for > any IProject error marker. Fair point, we can look for markers of type IJavaModelMarker.BUILDPATH_PROBLEM_MARKER to fix this. Reopening and marking for RC1.
This feature got implemented and verified for 3.6 M7. If there are bugs against a specific feature we don't reopen the 'feature' bug each time a bug for it is detected but open a new separate bug for each issue we detect.
