Home » Eclipse Projects » Eclipse Platform » Editor reuse broken in M5
| Editor reuse broken in M5 [message #160808] |
Sun, 23 November 2003 23:42  |
Eclipse User |
|
|
|
Sometimes it is necessary to have a particular file type open in a single
editor instance. There has been no explicit support for this in Eclipse
but there was a nice workaround for it up to and including version 3.0M4
that went something like this:
- 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 {
get the editor's description and mark it as internal
workbenchpage.openEditor(newInput)
set the editor as external so this launcher will be used again
}
There is now (from M5) no way to set an editor's internal/external
property in the EditorDescription so that this approach no longer 'works
around'.
There is a new IReusableEditor interface but I can't see how this helps at
the moment. Are there any plans to deal with single editor instances with
a working navigation history? If not, could we have setLauncher() and
setOpenMode() in EditorDescription made public so that the approach
described above will work again?
Thanks,
Henrietta
|
|
| | | |
| Re: Editor reuse broken in M5 [message #161845 is a reply to message #161490] |
Tue, 25 November 2003 18:26  |
| Eclipse User |
|
|
|
Thanks a lot Thomas,
This requirement would be common to a broad class of problems. Any time an
editor has a large startup time, consumes a lot of resources and is
configured
by a comparatively small 'edited file' then a singleton editor is
necessary.
Think 3D as one example.
>You can do ref counting; parts are disposed.
Could you explain in a little more detail what your wrapper solution
involves? Would these wrappers be EditorParts? If so these parts are owned
by the framework and are normally destroyed when you press the close
button.
How do you propose I do 'ref counting' and how would I get the framework
to drop a reference to an editor part when it doesn't have its own GUI
(it's delegating to the singleton). Doesn't an EditorPart have a good
deal of GUI baggage (hence the reasonable Site exception) and how would
you prevent this baggage from being created?
The approach you describe as 'hackery' is simple and has worked well sice
the
days of 2.0. Why prevent this broad class of problems from being solved
within Eclipse for the sake of making two methods public?
Martin
Thomas Mäder wrote:
> Henrietta wrote:
> > No, I'm afraid that doesn't work - in our proposed wrapper EditorPart's
> > init() method we would need to do:
> >
> > setSite( singleInstanceEditor.getSite() );
> >
> > because to do:
> >
> > setSite( site );
> >
> > just creates a new window as usual, but when our init() method completes
> > there is a guard in EditorManager that ensures we're connected to the new
> > site:
> >
> > private void createSite(...) throws PartInitException
> > {
> > ...
> > part.init(site, input);
> > if (part.getSite() != site)
> > throw new Exception("EditorManager.siteIncorrect" );
> > ...
> > }
> I don't understand this requirement. You'd have to expand on what
> exactly you're doing and why you can only have a single editor instance.
> >
> > So using the wrapper approach we get either new windows or exceptions. In
> > any case there must be a better way of organising this than creating a
> > whole editor part just to access a singleton? And when and how would
> > these new wrappers be destroyed?
> You can do ref counting; parts are disposed.
> >
> > Would it be possible to make those EditorDescription methods public so
> > the approach used in M4 and previous versions works again? In the absence
> > of some new reusable editor architecture, it's tried and trusted.
> It just smells like hackery, sorry (I can't speak for the platform team,
> though). Perhaps if you describe the whys and hows of your problem,
> somebody can suggest a better solution.
> >
> > Thanks,
> > Henrietta
> >
> > Thomas Mäder wrote:
> >
> >
|
|
|
| Re: Editor reuse broken in M5 [message #162081 is a reply to message #161845] |
Wed, 26 November 2003 06:14 |
| Eclipse User |
|
|
|
Originally posted by: thomas_maeder.ch.ibm.com
Henrietta wrote:
> Thanks a lot Thomas,
>
> This requirement would be common to a broad class of problems. Any time an
> editor has a large startup time, consumes a lot of resources and is
> configured
> by a comparatively small 'edited file' then a singleton editor is
> necessary.
> Think 3D as one example.
>
Aha, I see.
>
>>You can do ref counting; parts are disposed.
>
>
> Could you explain in a little more detail what your wrapper solution
> involves? Would these wrappers be EditorParts? If so these parts are owned
> by the framework and are normally destroyed when you press the close
> button.
The wrappers would be IEditorParts, and they would reference an instance
of the shared object. When eclipse calls the dispose() method on the
editor part, you decrement the reference count. Of course, if the bulk
of your editor is in the UI (i.e. the widgets), you're out of luck.
>
> The approach you describe as 'hackery' is simple and has worked well sice
> the
> days of 2.0. Why prevent this broad class of problems from being solved
> within Eclipse for the sake of making two methods public?
>
Your real problem is: "I'd like to always reuse the same editor
instance". The solution you had in earlier builds is a workaround
because you can't express what you really want in eclipse.
The real fix would be to add a method openEditor(..., boolean
reuseInstance) to the eclipse framework (file a bug report!). Sometimes
hackery is the only way you can solve a problem.
In the meantime, why don't you define two editors, one external and one
internal. You can set the external one as the default editor for the
particular file type you're interested in. In the open method of the
external editor, you do this:
MyEditorType existingEditor= findEditorInstance(file);
if (existingEditor != null)
editor.setInput(bla);
else
openInternalEditor(file);
your users could be fiendish and manually change the default editor
type, but that's their problem, not your's.
Thomas
|
|
|
| Re: Editor reuse broken in M5 [message #162539 is a reply to message #162081] |
Wed, 26 November 2003 17:16 |
| Eclipse User |
|
|
|
That's all really helpful. I had the same idea some time back with the
internal / external editor combo. Unfortunately, the navigation history
remembers that you opened the first editor as internal and when you do
ALT-LArrow or ALT-RArrow it's the internal editor that get's used again
and more windows pop up - no solution for me I'm afraid.
I'll look again at your wrapper approach but I can't currently see why
eclipse would "call the dispose() method on the editor part" unless it's
initiated by a close button on the GUI (which it wouldn't have). I guess
I'll have to try and close it myself from the singleton when the selection
changes (any idea how to do that?). If I can't get it working I'll do as
you suggest and file a bug report asking for:
openEditor(..., boolean reuseInstance)
Thanks a lot,
Henrietta
Thomas Mäder wrote:
> Henrietta wrote:
> > Thanks a lot Thomas,
> >
> > This requirement would be common to a broad class of problems. Any time an
> > editor has a large startup time, consumes a lot of resources and is
> > configured
> > by a comparatively small 'edited file' then a singleton editor is
> > necessary.
> > Think 3D as one example.
> >
> Aha, I see.
> >
> >>You can do ref counting; parts are disposed.
> >
> >
> > Could you explain in a little more detail what your wrapper solution
> > involves? Would these wrappers be EditorParts? If so these parts are owned
> > by the framework and are normally destroyed when you press the close
> > button.
> The wrappers would be IEditorParts, and they would reference an instance
> of the shared object. When eclipse calls the dispose() method on the
> editor part, you decrement the reference count. Of course, if the bulk
> of your editor is in the UI (i.e. the widgets), you're out of luck.
> >
> > The approach you describe as 'hackery' is simple and has worked well sice
> > the
> > days of 2.0. Why prevent this broad class of problems from being solved
> > within Eclipse for the sake of making two methods public?
> >
> Your real problem is: "I'd like to always reuse the same editor
> instance". The solution you had in earlier builds is a workaround
> because you can't express what you really want in eclipse.
> The real fix would be to add a method openEditor(..., boolean
> reuseInstance) to the eclipse framework (file a bug report!). Sometimes
> hackery is the only way you can solve a problem.
> In the meantime, why don't you define two editors, one external and one
> internal. You can set the external one as the default editor for the
> particular file type you're interested in. In the open method of the
> external editor, you do this:
> MyEditorType existingEditor= findEditorInstance(file);
> if (existingEditor != null)
> editor.setInput(bla);
> else
> openInternalEditor(file);
> your users could be fiendish and manually change the default editor
> type, but that's their problem, not your's.
> Thomas
|
|
|
| Re: Editor reuse broken in M5 [message #162578 is a reply to message #162081] |
Wed, 26 November 2003 19:27 |
| Eclipse User |
|
|
|
I've tried again with wrappers but I don't think it can be made to work.
When a new IEditorPart is created it has to accept the IWorkbenchPartSite
that it's given in init() (i.e. the same site must be returned from
getSite() or an exception is thrown). The IWorkbenchPartSite seems to
correspond visually to a new editor tab and there is no way of preventing
it's creation. I'm concluding there is no way of always reusing the same
editor in M5 and beyond and I've filed a bug report (47600) to that effect:
Thanks,
Henrietta
Thomas Mäder wrote:
> Henrietta wrote:
> > Thanks a lot Thomas,
> >
> > This requirement would be common to a broad class of problems. Any time an
> > editor has a large startup time, consumes a lot of resources and is
> > configured
> > by a comparatively small 'edited file' then a singleton editor is
> > necessary.
> > Think 3D as one example.
> >
> Aha, I see.
> >
> >>You can do ref counting; parts are disposed.
> >
> >
> > Could you explain in a little more detail what your wrapper solution
> > involves? Would these wrappers be EditorParts? If so these parts are owned
> > by the framework and are normally destroyed when you press the close
> > button.
> The wrappers would be IEditorParts, and they would reference an instance
> of the shared object. When eclipse calls the dispose() method on the
> editor part, you decrement the reference count. Of course, if the bulk
> of your editor is in the UI (i.e. the widgets), you're out of luck.
> >
> > The approach you describe as 'hackery' is simple and has worked well sice
> > the
> > days of 2.0. Why prevent this broad class of problems from being solved
> > within Eclipse for the sake of making two methods public?
> >
> Your real problem is: "I'd like to always reuse the same editor
> instance". The solution you had in earlier builds is a workaround
> because you can't express what you really want in eclipse.
> The real fix would be to add a method openEditor(..., boolean
> reuseInstance) to the eclipse framework (file a bug report!). Sometimes
> hackery is the only way you can solve a problem.
> In the meantime, why don't you define two editors, one external and one
> internal. You can set the external one as the default editor for the
> particular file type you're interested in. In the open method of the
> external editor, you do this:
> MyEditorType existingEditor= findEditorInstance(file);
> if (existingEditor != null)
> editor.setInput(bla);
> else
> openInternalEditor(file);
> your users could be fiendish and manually change the default editor
> type, but that's their problem, not your's.
> Thomas
|
|
|
| Re: Editor reuse broken in M5 [message #172427 is a reply to message #160808] |
Fri, 19 December 2003 08:39 |
| Eclipse User |
|
|
|
Originally posted by: daniel.megert.gmx.net
Henrietta,
if you didn't already do so the best would probably be to file a feature
request where you explain why this feature might be a good addition.
Dani
Henrietta wrote:
>Sometimes it is necessary to have a particular file type open in a single
>editor instance. There has been no explicit support for this in Eclipse
>but there was a nice workaround for it up to and including version 3.0M4
>that went something like this:
>
> - 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 {
> get the editor's description and mark it as internal
> workbenchpage.openEditor(newInput)
> set the editor as external so this launcher will be used again
> }
>
>There is now (from M5) no way to set an editor's internal/external
>property in the EditorDescription so that this approach no longer 'works
>around'.
>
>There is a new IReusableEditor interface but I can't see how this helps at
>the moment. Are there any plans to deal with single editor instances with
>a working navigation history? If not, could we have setLauncher() and
>setOpenMode() in EditorDescription made public so that the approach
>described above will work again?
>
>Thanks,
>Henrietta
>
>
>
|
|
|
Goto Forum:
Current Time: Sun Jun 08 17:17:58 EDT 2025
Powered by FUDForum. Page generated in 0.34973 seconds |
Home