Community
Participate
Working Groups
Abstract: Since 2.0 there were plans to make markerImageProviders public API. But the implementation in 3.0 seems to be even worse than in 2.1.3! Solve that by making this extension truly public API. Details: while porting our Quickmarks extension (see http://eclipse-tools.sourceforge.net/quickmarks/) from 2.1.3 to 3.0 I had to notice, that the 3.0 implementations around extension point markerImageProviders seems to be worse than before: in 2.1.3 our special icons show up (even on workbench startup by means of early startup requested by our plugin, when not opted out by the user, at least our special default icon is shown). In 3.0 this doesn't work any more, as long, as our Quickmarks are derived from problemmarker and/or bookmark. Our QuickmarkImageProvider class is never instantiated, the images show up as Problems or Bookmarks, depending on the order of naming the super types. But when ONLY deriving from org.eclipse.core.resources.marker, our image provider class IS instantiated and does it's job (even the early startup works). So it may turn out, that this request is actually a first indication of some real bug in 3.0, as there are other deficiencies in the showup of marks derived from both problemmarker and bookmark at the same time in 3.0 views (working in 2.1.3 and to be reported elsewhere). The problem seems to have to do with the implementation of org.eclipse.ui.internal.ide.registry.MarkerImageProviderRegistry. getImageDescriptor(IMarker marker). But aside from 'might be a bug in 3.0' the fact remains: this extension point should be really turned into public API finally! This would force cleanup of all related APIs and implementations. I don't have to argue for the usefullness of this extension point? See https://bugs.eclipse.org/bugs/show_bug.cgi?id=1882 for very informative IMarkerImageProvider concepts and an early request to make this public API in 3.0. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=29448 for confirmation, that the extension point is/should be 'promoted and supported' since Eclipse 2.1. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=36418 for another early request (against 2.0) to make this public API and notes about things, that must be changed to fully support IMarkerImageProvider. There are even other requests in NEW state and unprocessed/uncommented. Finally see https://bugs.eclipse.org/bugs/show_bug.cgi?id=37741 for another request for public API and the lapidar comment 'not for 3.0'. 3.0 is out. So NOW is the time for a public API! Thanks all Eclipse developers for your GREAT 'for nothing ...' software! Best regards, Georg
Moving to Nick as he owns the previously mentioned Bugs
Inspection of the implementation in org.eclipse.ui.internal.ide.registry.MarkerImageProviderRegistry. getImageDescriptor(IMarker marker) reveals, that the method looks for providers in the (arbitrary) order they where registered. As soon as the marker is ANY subtype of an early registered descriptors marker type the search stops and the descriptor for that super type is returned. I would preferr the variant (1) as suggested by Nick Edgar in https://bugs.eclipse.org/bugs/show_bug.cgi?id=36418 where the most specific image provider is returned. One prerequistite would be to change the MarkerImageProviderRegistry to be able to access the registered providers by marker type (e.g. a Map, keyed by marker type, instead of the used ArrayList for storage). The other would be, as Nick already has proposed, adding new core API to expose the marker type hierarchy. E.g. a method IMarker.getAllSuperTypes(), defined as: /** * Returns all super types of this Marker. The first entry(s) of * the array returned contain(s) the direct supertype(s), later * entries super-supertypes (if any). Note, that you can't tell, * where the boundary between direct super type(s) and super-super * type(s) is in the returned array. * @return the array with super types or null */ public String[] IMarker.getAllSuperTypes() throws CoreException; would be good enough for the intended change of MarkerImageProviderRegistry. As IMarker is NOT intended to be implemented by developers this new method still preserves API and binary compatibility as far as I can see. The neccessary implementation exist already (almost) for the IMarker.isSubtypeOf() (all mentioned classes in package org.eclipse.core.internal.resources): Marker.isSubtypeOf(String) is delegatet to MarkerManager.isSubtype(String, String), which in turn delegates to MarkerTypeDefinitionCache.isSubtype(String, String). MarkerTypeDefinitionCache has a method computeSuperTypes(String), that essentially processes all super types of the given marker type in the correct order inside it's loop, all direct super types first, then super-super types, then super-super-super types etc., but currently stores the types in a (Hash)Set, to be sure to have no dups stored. If it would instead store (after a check for dups) in an ArrayList, then it would be easy to implement a new method getAllSuperTypes() with an implementation of essentially: public String[] getAllSuperTypes(String type) { List entry = (List) lookup.get(type); if (entry != null) { return (String[]) entry.toArray(); } return null; // or an empty array? } Access to this new method would be similar to Marker.isSubtypeOf() by delegation. I hope these observation help having a better MarkerImageProviderRegistry soon? Best regards Georg
Oops, the suggested new IMarker interface method shall read: /** * Returns all types of this Marker. The first entry of the returned * array always holds the id of the IMarker at hand. Later entries are * the direct supertype(s), followed by super-supertypes (if any) etc. * <p> * Note, that you can't tell, where the boundary between direct super * types and super-super types is in the returned array. * * @return the array with types */ public String[] IMarker.getAllTypes() throws CoreException; Georg
cc'ing DJ for the suggested core API.
Created bug 70381 to cover new API issues.
We should also clarify/consider annotations which are shown in editors and can be provided using the following extension points: org.eclipse.ui.editors.annotationTypes org.eclipse.ui.editors.markerAnnotationSpecification
I vote for this bug (and all the similar but separately reported ones!) to be fixed as well. I find that I can customize the marker indicator along the side of an editor using the annotationTypes and markerAnnotationSpecification extensions, but cannot customize the Problems View. The markerImageProviders extension seems the logical place to provide a custom icon for a marker, wherever it is displayed. One additional comment. It does not look to me like the image registry is the only problem. The Problem View is an instance of a TableViewer, with a hardcoded first column that is a FieldSeverity. The paths to the icons are hardcoded in FieldSeverity. However, FieldSeverity.getImage could ask its argument for an image proivder, if it has one, and get an image that way (although the problem really needs to be solved for Markers in general).
*** This bug has been marked as a duplicate of 1882 ***
As Bug 1882 now is marked RESOLVED REMIND with comment "There are currently no plans to work on this feature" I'm no longer happy with having this bug report marked as a duplicate of bug 1882. As can be seen from my original description I reported a real problem which isn't solved (even not in 3.2.1 M20060118- 1600) repeated here for clarity: The Quickmarks are really Bookmarks with 2 special features: they are settable/jumpable to with just a key stroke (working through my plugin) and they have special images, to identify them easily. The display of the special images works, as long as the Quickmarks are derived from only org.eclipse.core.resources.marker, through the plugins use of the extension point org.eclipse.ui.ide.markerImageProviders and a subclass of the org.eclipse.ui.internal.ide.IMarkerImageProvider. As soon as I derive the Quickmarks from org.eclipse.core.resources.bookmark (or org.eclipse.core.resources.problemmarker or org.eclipse.core.resources.taskmarker for that matter) the QuickmarkImageProvider isn't invoked any more. Instead of the special images a Bookmark (or Taskmark or Problemmarker) is shown in the annotion bar instead. As can bee seen from Bug 36418 comment #1 there exists a problem with the image registry and as can be seen from comment #7 in this bug there are additional problems with at least the Problem View using hardcoded images instead of asking the image provider. My subject "make this finally public api" really should force: "get that whole issue finally fixed"! So I ask for reopening this bug. At most I think this could be a duplicate of Bug 36418, which is still in NEW state, but maybe better the other way round AND GET THAT FIXED.
*** This bug has been marked as a duplicate of 36418 ***
