Community
Participate
Working Groups
For editors that have long startup times or consume a lot of resources it is necessary to use a singleton, i.e. one editor instance is always reused for a file type whether it be opened by double-clicking the file, or opened programatically or from the navigation history (A 3D editor might want this, for example). Up to and including Eclipse 3.0 M4 it was possible to achieve this using the following workaround: - define an external editor launcher in whose open() method we do the following: if the editor is already open { editor.markInNavigationHistory editor.setInput(newInput) } else { EditorDescriptor desc = ...; desc.setInternal( true ) workbenchpage.openEditor(newInput) // set the editor as external so this launcher will be used again desc.setInternal( false ) } From M5, the required method calls have changed slightly and look as though they would be: desc.setOpenMode( EditorDescriptor.OPEN_INTERNAL/EXTERNAL ); Unfortunately, this method now has package visibility and can't be used. In the medium to long term it would be nice to have a proper solution to this requirement by adding something like "reuse=true" into the editor's extension point in the plugin.xml. But in the very short term (in time for M6 or before would be good!) could we revert setOpenMode() back to public visibility? For a discussion on some of the other things that were tried (and failed) for solving this problem see the "Eclipse reuse broken in M5" thread in the platform newsgroup. Thanks, Henrietta
Note that EditorInput and its set methods were never API (the API interface is IEditorInput), so this was not a supported scenario even prior to the changes in M5. However, I do understand the need to reuse expensive editors. One thing we are considering for 3.0 is a way to allow a plug-in to define how an object gets opened in an editor. e.g. there would be API like openEditor (Object element) which would look up the best matching strategy for converting the element into an IEditorInput, finding the best matching editor, and perhaps even taking care of the actual opening of the editor (there may be multiple pluggable strategies here). This is an interesting use case for such a mechanism. Could you provide more details on the following: - What kind of object are you opening the editor on? Is it a regular workspace file or something else? - Where does the code above gets run? Is it in a particular view? What if your file gets opened from some other view like the Navigator? What is the desired behaviour in this case? - How do you get the editor descriptor? Is it the same descriptor as for the external launcher, that you just look up from the registry? Could you not use two different editor descriptors (one for the external launcher, and one for the actual editor you want to open)? I'll also take a look at the newsgroup thread.
Could you provide more details on the following: > What kind of object are you opening the editor on? Is it a regular workspace file or something else? Just a regular workspace with a particular filename extension that gets opened by my editor. > Where does the code above gets run? Is it in a particular view? What if your file gets opened from some other view like the Navigator? What is the desired behaviour in this case? The example code was from a specialized editor launcher defined in my plugin.xml. The desired behaviour when used from the navigator is the same as from anywhere else; open the new input in a single instance of the editor or create the instance if doesn't already exist. > How do you get the editor descriptor? Is it the same descriptor as for the external launcher, that you just look up from the registry? Could you not use two different editor descriptors (one for the external launcher, and one for the actual editor you want to open)? That's right, the desciptor comes straight out of the registry. The problem with using two descriptors (if I understand you correctly) is that whenever 'the actual editor I want' is opened directly, rather than through the external launcher, the naked editor (without launcher) is stored in the navigation history which forces multiple instances of the editor to be created when the navigation history is used.
The newsgroup thread is actually called "Editor reuse broken in M5".
See bug 5687 for an early request for making the process to open an editor on a particular object more open.
Although we normally don't make our internal methods public so other plugins can call them, in this case I don't see an alternative solution to your problem using the current public API. Since you previously had a workaround, which is now broken due to changes that went in with the RCP changes in M5, and since this change was actually somewhat gratuitous (not directly required for the RCP work), I'm making setOpenMode and the related constants public for now. Changes will be in the M6 build.
Opened bug 48767 for the general problem of managing heavyweight editors. Closing this one.
