Community
Participate
Working Groups
If i create my handy dandy editor for XML files and supply it as an Update Manager feature. If the user has been working on a workspace already and now my feature gets added the user has to know exactly what was installed and how to find it. What is needed is a way for a new feature to announce itself to the user the first time it comes up after being installed. At this point if it provides some editors or perspectives the user should be allowed to set the default perpspective/editors for files to the new editor/perspective. The plugincustomization.ini is only useful the first time the user starts with a fresh workspace. It doesn't handle this case. This is important for WebSphere Studio Tools as when the user upgrade from one product to another there is no way to make the new function the default or even give the user the option to do so
This is a stop ship defect for us. I have raised the priority accordingly. It is critical that extensions be able to optionally ask the user during their install (e.g. product upgrade case) about the new capabilities and allow those capabilities to be configured. The current preference override mechanism is inadequate for this.
Needed for 2.0.1. To clarify, do you want to prompt the user to switch editor associations at install/update time or at run time?
Could do the following: - Product 1 provides editor A for file extension .ext, and is not tagged as being the default editor - Product 2 is later installed, and provides editor B for file extension .ext, and -is- tagged as being the default editor Before Product 2 is installed, editor A will be used. After Product 2 is installed, editor B will be used. The exception is that files which were previously opened using editor A remember it as being the editor to use, so will open using editor A even after product 2 is installed. If this is fixed, this would solve the problem. There is an existing PR for this: bug 21486.
The second exception is that once the user opens the File Associations preference page, we save a file with ALL the information instead of saving only what the user changed. So next time the workbench is started, it overrides what is set in the plugin.xml(s) and the default settings from the product ini. The fix for bug 21486 is simple but the fix for the preference page is a bit more complex. Once these two things are fixed we would have the behavior Nick has described, independent if the first product set the default editor or not. The exception would be if the user set a 3rd editor as the default.
Released EditorRegistry and FileEditorMapping in the HEAD stream. Implemented according to comment: "Nick Edgar 2002-07-24 14:45". Need to know if this fix is enough before releasing it in the 201 stream.
In addition to overriding the default, they also want the ability to delete the old mapping. The scenario is: - product A registers a generic XML editor for WSDL files - product B comes along with a real WSDL editor - product B wants to delete product A's mapping for WSDL files (not just change the default) We have the ability to manually delete registered mappings. Need to look at allowing this to be done programmatically or via the registry.
Currently we do not ship our product by taking advantage of the Update Manager. We ship product A's plugins(untouched) with product B and laid down a new copy of Eclipse. So when the workbench is started we want product's B default WSDL editor to be registered and not product's A generic XML editor which is described in the plugin.xml as a default editor for WSDL as well. Other editors that are registered for the WSDL files are ok as along as they are not the default becuase it is unpredictable which one wins. We would like the product.ini to handle the deregistering of the product A's editor with the WSDL extenstion, totally remove it from the association. When we move to the Update Manager based install this will also need to be available as mentioned comments "Nick Edgar 2002-08-01 09:56"
As I undestand we have two distinct problem here: 1) overriding the default editor (very important - P1 blocker) 2) de-registring an editor (not important - P3 - minor). About 1: Would it be enough to fix the problem if we guaranty that editor from product B would be used in the following scenario? * Product A has a editor for "*.foo" (default or not) * Product B has a new editor for "*.foo". Product B makes sure its editor is the default by setting it on the plugincustomization.ini. So product B would be overriding the primary feature. Is that the case here? Are you guys shipping a new primary feature? BTW, is the editor from product A marked as default in this case? About 2: I am not convinced that this is the answer for the problem. I would few more comfortable not fixing it now (2.0.1) and talking about it a bit more LATER.
In case you guys are not shipping a primary feature we could add API to IEditorRegistry to set the default editor and save the registry. Some thing like: - IEditorRegistry.setDefault(String fileNamePattern,String editorId) - IEditorRegistry.save() So when ever you start the workbench you can change the default editor. Note that if you do it by changing the primary feature ini file is makes it independent of the workspace but if you do it on "runtime" it is only valid for that workspace. So you would have to do a checking everytime the workbench is started.
You are correct, there are two distinct problems. Answers to questions posed in the comments "Eduardo Pereira 2002-08-12 15:11", section "About 1:" * Yes this would be sufficient. * We are overriding the primary feature. * We are shipping a new primary feature. * The editor in Product A is marked as default, so is the editor in Product B.
As per a discussion I had with Kevin H. We can provide an experimental API for 2.0.1 to solve this editor problem. We would provide a new attribute in the editors extension point. With this new attribute, the developer would be able to specify which editor it is overriding. This would cause the overriden editor to be removed from the list (Open With...). For example. Plugin A provides a default editor E1 for *.foo files. Plugin B provides a default editor E2 for *.foo files, and overrides E1. When the editor extensions are read from the registry, the *.foo mapping will have E2 as the default editor, and E1 not listed as an editor for *.foo files. Is this acceptable for 2.0.1? It's not a complete story for overrides, but it does address the current editor problem raised in this PR. Please reply as soon as you can as the code freeze deadline is almost here.
Code released in 2.0.1 stream
*** Bug 22644 has been marked as a duplicate of this bug. ***
In "Additional Comment #8 From Eduardo Pereira 2002-08-12 15:11", Eduardo mentions that the plugincustomization.ini can be used to override the default editor. Is this correct? What would the entry in the .ini file need to be? Did this make it into 2.0.2?
Bug 21347 contains an attached example showing how to do this for the case where WSADIE is installed on top of WSAD after the fact. This uses a different approach than described in comment #8. Basically the plugins for any new features are started up when the workbench notices the new features coming in. The startup code can access the editor registry, and add/override entries. The startup code should ensure that it is only run once.
