Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. Create your own marker type through the org.eclipse.core.resources.markers extension point. 2. Specify an image for the marker using the org.eclipse.ui.ide.markerImageProviders extension point. 3. Note that neither specifying an icon directly nor creating a class implementing IMarkerIMageProvider causes a marker image to be displayed with the marker in the Markers view. Also note that the getImagePath(IMarker marker) method on IMakerImageProvider implementing class never gets called. More information: The problem appears to be in classes extending the abstract class MarkerDescriptionField. Implementation of the method getImage(MarkerItem item) appears to be incorrect. For example, in MarkerProblemSeverityAndMessageField, it appears that the marker image is never retrieved - only an image for the severity is returned. I think what should happen is if a marker has an image specified, that image should be used, otherwise, the severity image can be used as a default. Also look at MarkerSeverityAndDescriptionField's getImage(MarkerItem item) method.
Also see Bug 26029.
Bug 36418, Bug 121538 indicate that this extension point is not yet API. Also see Bug 36418 comment #1. Tod, can you please shed some light on this ?
We have never had the push to make this API because it has some inflexibility that made it generally not consumable - it was written early on to enable the first marker views for the 3 severities we use and as a result was not used by the markerSupport as it was not API. It is confusing that we have an internal extension point (we don't generally do that) but removing it would likely break someone without warning. It will require integration with markerSupport and some work on API. However it will bring up some difficult use cases - for instance if someone sorts on severity which icon should we use?
Created attachment 124016 [details] possible solution (?) Thanks Tod. Are you referring to the inflexibility also mentioned on Bug 36418 comment #1? I have attached a patch to the bug demonstrating my thoughts towards a possible solution. The MarkerTypesModel and MarkerType provide enough API to > (1) find the marker image provider that most closely matches the given marker's > type (i.e. fewest steps in the supertype chain) > It will require integration with markerSupport and some work on API. However it > will bring up some difficult use cases - for instance if someone sorts on > severity which icon should we use? > Since markerGrouping need not always be based on severity, a different icon may be desired and be indicative of the grouping criterion in such a case.Let markerGroupingEntry have 'icon' as an optional attribute ? Could you please share your suggestions and your thoughts on the patch?
Created attachment 124017 [details] Snippet to test the patch
I think generally the ideas are pretty good - the list below may look long but there are all pretty small issues. This has been a long standing feature request so I think it is worth pushing forward on. As MarkerSeverityAndDescriptionField is not API I don't think you need a new class MarkerIconSeverityAndDescriptionField as you don't use both. Just change MarkerSeverityAndDescriptionField. MarkerGroupingEntry should use MarkerSupportInternalUtilities.ATTRIBUTE_ICON rather than defining it's own icon class. I'm not exactly sure what you are doing in TypeMarkerGroup#findGroupValue. Why does not call the superclass? I am concerned with the image lookup being used when creating MarkerCategories in the buildHierarchy method. This happens all of the time (everytime the user saves) and so trying to figure out the image seems like a bad idea. You should look up images after the sorting is done for performance reasons. A couple of style things: 1) Try to use positive logic - if you can avoid using if(!condition) falseBlock it is more readable 2) You don't seem to be using the formatter which makes it hard to read. This may have been to make the patch easier however. 3) As this is a big patch try and clean up the warnings when it gets committed 4) Javadoc all new methods as it makes it hard for others to see what you were doing othereise 5) Don't forget the since markers for the new attributes in the schema 6) The javadoc for TypeMarkerGroup#findGroupValue is wrong
Created attachment 124416 [details] Patch (In reply to comment #6) I have updated the patch incorporating your suggestions. > I'm not exactly sure what you are doing in TypeMarkerGroup#findGroupValue. Why > does not call the superclass? > TypeMarkerGroup is bit different compared to MarkerGroup in how it groups; it does not declare any grouping entries or attribute mappings, it simply uses the different types as different groups. > I am concerned with the image lookup being used when creating MarkerCategories > in the buildHierarchy method. This happens all of the time (everytime the user > saves) and so trying to figure out the image seems like a bad idea. You should > look up images after the sorting is done for performance reasons. > The 'buildHierarchy' happens after sorting (see method sortAndMakeCategories) . Actually, lookup for a type happens only once and is cached for later use. I'll be posting a few tests for this shortly. Note: The class IMarkerImageProvider is still in an internal package. Your thoughts? Thanks.
Created attachment 124787 [details] tests code
Created attachment 124788 [details] tests icons place in org.eclipse.ui.tests/icons
Adding Boris for review....where should we put IMarkerImageProvider?
Hitesh, thanks for all of your work on this but after a talk with Boris we think that it is too late in the cycle to add it in now (our fault, sorry). This does not mean that we don't want the fix we're just ensuring that we err of the 'safe side' rather than jamming in an extensive API change late in the game... Please keep track of this defect and we can return to it in 3.6...
I am new Eclipse' user and I've have the follow problem when I debug Applets in option Run... Exception in thread "main" java.lang.NoClassDefFoundError: sun.applet.AppletViewer at gnu.java.lang.MainThread.run (libgcj.so.7) Caused by: java.lang.ClassNotFoundException: sun.applet.AppletViewer not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/home/alunos/rcaldeira/workspace/DEITEL/], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass (libgcj.so.7) at java.lang.ClassLoader.loadClass (libgcj.so.7) at java.lang.ClassLoader.loadClass (libgcj.so.7) at java.lang.Class.forName (libgcj.so.7) at gnu.java.lang.MainThread.run (libgcj.so.7) BECAUSE when I run option Run... in main pallete there is a checkbox for component checkbox Applet viewer: sun.applet.AppletViewer that is checked and them when the checked button is off so it desability button Run and I can-t run anymore. So I do not know what can I run my applets into Eclipse. On the other hand, I am using html browser for call it, but I would like to run applets using appletviewer into Eclipse, wouldn´t I? In resume: I would like to use appletviewer into Eclipse. Is it possible or not? Thanks
Rosane, being new I'll comment nicely...you should ask questions like this one in the newsgroups since you're asking whether /how something can be done. Most certainly you *MUST NOT* randomly attach questions onto defects completely unrelated to the issue being worked on...
Hello, it has passed quite some time after the last post about this issue and this bug was open, so now I'd like to know if there is any easy workaround I can make to have custom marker icons in the "problems view", a "markers view", or someother view ... Thanks Mário
*** Bug 26029 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > ... I'd like to know if there is any easy workaround I can make to > have custom marker icons in the "problems view", a "markers view" ... I don't think so.
Is there any movement on this? I'd really like to see this bug nailed and this functionality available. Is there something I could do to assist getting this resolved?
(In reply to comment #17) > Is there something I could do to assist getting this resolved? If you are interested, you could continue work on the patch in http://git.eclipse.org/c/platform/eclipse.platform.ui.git Bring it up so it applies to master, then we can evolve it. See also http://wiki.eclipse.org/Platform_UI/How_to_Contribute PW
(In reply to Paul Webster from comment #18) > (In reply to comment #17) > If you are interested, you could continue work on the patch in > http://git.eclipse.org/c/platform/eclipse.platform.ui.git > > Bring it up so it applies to master, then we can evolve it. > > See also http://wiki.eclipse.org/Platform_UI/How_to_Contribute > > PW > Hi Paul, and everyone. Is the patch still relevant anymore? What can I do to help get this longstanding bug resolved? Thank you, Chris Boyd
(In reply to Chris Boyd from comment #19) > (In reply to Paul Webster from comment #18) > > (In reply to comment #17) > > If you are interested, you could continue work on the patch in > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git > > > > Bring it up so it applies to master, then we can evolve it. > > > > See also http://wiki.eclipse.org/Platform_UI/How_to_Contribute > > > > PW > > > Hi Paul, and everyone. > > Is the patch still relevant anymore? What can I do to help get this > longstanding bug resolved? I can't say anything about patch, but yes, if you would like to see the problem fixed, you can follow the Paul's recommendation.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
