Community
Participate
Working Groups
The icon that I have associated with my custom editor does not appear beside matching files in the Package Explorer/Navigator views. I have defined a custom editor which uses the contentTypeBinding tag rather than the more generic 'extensions' parameter to associate my custom XML files to the editor. I've also defined a custom content type (via org.eclipse.core.runtime.contentTypes) which uses the org.eclipse.core.runtime.content.XMLRootElementContentDescriber describer to match on particular xml files. This scenario works perfectly well for opening/editing one of my custom XML files (ie. Eclipse properly opens my custom editor rather than the generic text editor). However, the icon is incorrect. Please note that the correct icon does appear in Eclipse 3.1.0. In Eclipse 3.1.1 and later (3.2.0 M3), the icon is incorrect (the generic text editor icon appears). The id of my sample plugin is com.sample.myplugin. The relevant plugin.xml snippets appear below: <extension point="org.eclipse.core.runtime.contentTypes"> <content-type file-extensions="xml" priority="high" name="My Custom XML File" id="MyCustomXMLFile" base-type="org.eclipse.core.runtime.xml"> <describer class="org.eclipse.core.runtime.content.XMLRootElementContentDescriber"> <parameter name="element" value="mycustomxml"> </parameter> </describer> </content-type> </extension> <extension point="org.eclipse.ui.editors"> <editor class="com.sample.editors.MyCustomEditor" contributorClass="com.sample.editors.MyCustomEditorContributor" default="true" icon="icons/editor.gif" id="com.sample.editors.MyCustomEditor" name="My Custom Editor"> <contentTypeBinding contentTypeId="com.sample.myplugin.MyCustomXMLFile"/> </editor> </extension>
This bug seems to be related to bug #107121.
Yes, this bug is a direct consequence of the fix for bug 107121. I hashed out a possible fix that would use the icon returned by a simple filename match initially and then fill in the proper icon in a background job but this is a non-trivial fix. In fact, IIRC, it would recall some pretty radical re-factoring of the workbench label providers among other things. MvM, I can look into this if you'd like but I'd guess this is going to take upwards of 3-5 days to get done at least. I'd be more inclined to mark this as either WONTFIX or LATER.
Thanx for the quick reply. This is definitely not a critical issue for me, but rather a minor nuisance. What about setting the proper icon once the associated editor is opened for the first time? While you are invoking the more "expensive" code (contentTypeBinding) to figure out which editor should be opened, you might as well set the proper icon at the same time.
The problem is that we don't have the infrastructure to communicate back to the label provider that one of their label images has changed. The fetching of the image isn't the problem so much as the fact that we'd need to invent a whole new communication layer with the label providers.
We're not going to have time to look at this in the 3.2 timeframe, unfortunately. Marking as LATER.
(In reply to comment #5) > We're not going to have time to look at this in the 3.2 timeframe, > unfortunately. Marking as LATER. > Could I suggest a slightly quicker, if temporary, fix. We could 'eveluate' the likeliness of Describers guzzling resources in various ways. Including some project specific stats... If we accept the idea, we could have for example, in org.eclipse.ui.internal.ide.model.WorkbenchFile#getBaseImage ... if (resource instanceof IFile) { if ( resource.getProject().hasMoreThanSettingFiles() ) // I want precise Icons contentType = IDE.getContentType((IFile)resource); else // I have too many files contentType = IDE.guessContentType((IFile)resource); } Not just because I like to see the little ant even when my ant file is not called build.xml... I'm under the impression that this regression from 3.1 will generate a substantial number of bug reports for various xml files.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
