Community
Participate
Working Groups
in RC1 when I double click on a build.properties file I get a Build Properties editor. If I double click on a plugin.xml or manifest.mf I get a Plugin Editor which has build properties and build.properties tabs. This is confusing. There should be one mainline way of editing these files. It should always use the cool new unified editor.
Jeff, we regret this but we were not able to register the cool new editor for build.properties. The problem is that with the 3.0 platform UI support, only one editor can claim to edit any particular file or a set of files with the same extension. Since both plugin and feature projects need to handle build.properties, we could not register both plug-in and feature manifest editor to edit build.properties. For this reason, we had to use the same new cool editor infrastructure to create a standalone build.properties editor that will handle this file. What we really need is some kind of logic that picks the right editor based on the context (i.e. the project it belongs to). That way, we would be able to choose plugin or feature editor to open build.properties depending on the project nature. Sadly, we cannot do it today.
could you not register an editor for build.properties that does the check (am I in a feature/plugin/fragment) and then delegates to the appropriate cool editor implementation?
I am not sure we can pull such a trick - it is definitely strange to have an 'editor' that is really a branch that opens a 'real' editor depending on the context.
related to this, I noticed that when editing a fragment that has a fragment.xml and a manifest.xml I ended up with two full fragment editors open. This was very confusing as I made changes in one and then happened (due mostly to difficulties in managing open editors) to look in the other and the changes did not appear to be there. I did not even notice that I had two until I started closing the various editors and was left with two with the same title.
Once the Platform/UI team addresses bug 53700, then all this confusion would go away.
Created attachment 19285 [details] Patch against PDE UI for using IEditorMatchingStrategy and IShowEditorInput This patch shows how to use the new IEditorMatchingStrategy and IShowEditorInput mechanisms described in bug 74263 to solve the problem described here.
Note that the patch is just a prototype. Some things to be aware of: - not sure whether the manifest editor takes other kinds of input besides IFileEditorInput - not sure whether the filename treatment in the matcher is accurate: - should it use toLowerCase() - should it always match all candidate files, or just the ones actually open in the editor? - the other PDE editors haven't been addressed - the IShowEditorInput support ignores the form-based pages, it only finds the source pages, which may not be what you want
In my opinion, this bug no longer depends on bug 53700 due to the new support described in bug 74263.
fixed. thanks Nick.
