Community
Participate
Working Groups
The plugin.xml registration allows the user to register a new editor for a file type. However, there is no public API to register file associations? There is a public interface, IFileEditorMapping, for accessing this information but none for creating a new one. Could you add an API for dynamically registering an editor (not just XML)?
Please could you add a use case for this API? Why do you need to dynamically change the bindinds?
I have enclosed a snippet of code that uses some internal Eclipse classes ( FileEditorMapping, IFileEditorMapping, EditorDescriptor). Obviously we want to get away from it and we are looking to use public APIs instead. The purpose of this code is to register an editor with a file type that could be defined in a other plugin. The plugin.xml registration allows you to register a new editor for a file type which is subtly different than what we have. FileEditorMapping newType = new FileEditorMapping(ext); newType.setDefaultEditor((EditorDescriptor)xmlEditor); IFileEditorMapping[] oldMap = registry.getFileEditorMappings(); FileEditorMapping[] newMap = new FileEditorMapping[oldMap.length + 1]; for (int i = 0 ; i < oldMap.length; i++){ newMap[i] = (FileEditorMapping) oldMap[i]; } newMap[oldMap.length] = newType; registry.setFileEditorMappings(newMap); registry.saveAssociations();
Trying to understand the reason for this API: Lets say we have an editor that can open *.gif files. I don't understand why would you have to tell that editor that it can open *.bmp files. Shouldn't the editor know which kind of files it can open? If the editor does not understand bmp, it would fail to open it. If the editor can open bmp then it should be specified in the editor declaration in its plugin.xml.
We have an xml file that we need to distinguish from other xml files for our processing. So we make its extension .qb rather than .xml. But we would still like to use the standard XML editor on this file type. There is a manual user interface that allows registering the editor for .qb files to be the standard XML editor. When our plugin is active we would like an api which will allows us to check to see if .qb is already registered to be edited by the XML editor and if not, an api which allows us to configure it to be so.
Not sure if we will be able to implement this API by 2.1. If we did it would be an extension point. But you could extend org.eclipse.ui.editors extension point with a new editor that actually points to the same class that the xml editor uses. So you would have your QT editor without using internal API and without implementing anything. Thoughts?
Thanks for your comment. Adding an extension point is exactly what we're looking for. Thanks.
There are no plans for the UI team to work on this defect until higher priority items are addressed. If you would like to work on this defect, please let us know on the platform-ui-dev mailing list.
*** Bug 32550 has been marked as a duplicate of this bug. ***
Hi just my small contribution which I know to be the wrong way to do it: Here is the bypass I am using to add a new extension to an existing Editor. As explained by Eric Chaland, we need these new API (#32550) for adding properly new extensions to existing editors. EditorDescriptor theEditor = (EditorDescriptor) editorRegistry.findEditor (THE_EDITOR_ID); if (theEditor != null) { try { List extension = new LinkedList(); extension.add("myext"); List filenames = new LinkedList(); editorRegistry.addEditorFromPlugin(theEditor, extension, filenames, true); } catch (Exception e) { //NoSuchMethodError in Eclipse 2.0 but ok in 2.1 } } else { logErrorMessage(THE_EDITOR_ID + " not found"); } Regards
Created attachment 17955 [details] patch to add a file-association element to org.eclipse.ui.editors extension point Bug 81829 shows WTP experiencing the same problem. I propose solving it not by adding new API, but by adding a new configuration element to the existing extension point. This patch is for org.eclipse.ui.internal.registry.EditorRegistryReader class. Please consider it for 3.1. Example usage: <extension point="org.eclipse.ui.editors"> <file-association default="false" extensions="tld, nst, xmi, dadx, wsdl, xsl" editor="org.eclipse.wst.xml.ui.StructuredTextEditorXML"/> </extension>
Will consider for 3.1
Created attachment 17973 [details] ensures that associations aren't processed until after all EditorDescriptors are created
I hate to be a nuisance, but one month has passed. Any feedback on the patch and status on whether it will go in? As a modification to an extension point, I'd expect it to have to be in by M6 or not at all.
I'm sorry. It's unlikely that this will go in for 3.1. There simply isn't enough time, and there are higher priority items....
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
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. If you have further information on the current state of the bug, please add it. 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.
