[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Editor Reuse and the Debugger
|
My thoughts on the matter are:
- we should not have editor management policies that differ on a
per-perspective basis, because the editors are shared across perspectives
in the same window
- if at all possible, there should be a single, global policy, and not
separate modes depending on context
I feel that the debugger should just use the default policy, calling
openEditor whenever a new file is selected or stepped into.
It should not do its own editor management.
The improvements to the editors dialog will help mitigate the problems
with having many open editors (e.g. it will be easy to close all but
current).
Alternatively, if the user has the reuse option on, with a reasonable
threshold, they will not mind if new editors are opened.
For browsers like the Java Browsing perspective, they should do their own
editor management.
However, this can lead to inconsistencies since editors are shared across
perspectives.
E.g.
- in Java perspective, open 5 editors
- switch to Java Browsing perspective
- it now has 5 editors open, even though it normally tries to keep only 1
open
- it is now indeterministic as to which one gets reused, so there is
potential for user confusion
Nick
Eduardo_Pereira@xxxxxxx
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
03/25/02 09:09 AM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-ui-dev] Editor Reuse and the Debugger
>Does (1) mean that the currently deprecated API will no longer be
deprecated and can be used?
No. It means that the currently deprecated API is going to be deleted. The
threshold is a global preference and we think it would bring confusion if
we made it configurable per perspective.
We did not find a unique solution that would work on all scenarios so if
you think Java Browsing needs a different behavior it may have to be done
at JDT level.
PS. If you are going to do exactly like the debugger then I will repeat
the answer for (2): "If you need any support from us, let us know.
Specially if (1) becomes too complicated."
>Does <<- provide the user preference "number of open editors before
closing" (disabled by default)
There is a check button (Enable/disable) and an text entry field (to enter
the number).
Eduardo.
Daniel_Megert@xxxxxxx
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
03/25/2002 05:07 AM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-ui-dev] Editor Reuse and the
Debugger
Does (1) mean that the currently deprecated API will no longer be
deprecated and can be used?
If so then the following problems still have to be solved:
- cloning a perspective copies the current editor reuse threshold and this
value can't be changed later (neither through the global preference nor
through the custom e.g. Java Browsing preference. See 10010 for more details.
- perspectives which are in the same window share the page. Because the
reuse editor threshold is stored in the layout but cached upon creation
inside the page it is not possible to change the property for perspectives
which are not active. See 9392 for more details.
Does <<- provide the user preference "number of open editors before
closing" (disabled by default)>> mean that there's a checkbox with a field
where the number can be entered?
Dani
Eduardo_Pereira@xxxxxxx
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
03/22/02 07:19 PM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-ui-dev] Editor Reuse and the Debugger
We are changing the way we have addressed this problem. Up to now we said
that the platform UI should do the management so debug, search, java
browsing perspective and others would have exactly the same behavior. We
concluded that we can't come up with a single, simple and explainable
solution that would fit and fix all the scenarios and usages of editors.
So we are going to address the problem in a simpler way. The platform
will:
- provide the user preference "number of open editors before
closing" (disabled by default). And that will be the only strategy to
reduce the number of open editors provided by the platform.
- remove the pin editor button which is considered to add a new mode
to the UI.
- provide ways to help the user to manage lots of opened editors.
That includes changes to switch editors dialog such as adding two more
buttons: select clean editors and invert selection. That should help the
user to close all non-interesting editors as well as finding an open
editor.
So the short answer is:
> (1) Should we fall back to the custom editor reuse policy?
Yes.
> (2) Is there some support that we can leverage from the workbench?
If you need any support from us, let us know. Specially if (1)
becomes too complicated.
Eduardo.
Darin_Wright@xxxxxxx
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
03/22/2002 11:16 AM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: [platform-ui-dev] Editor Reuse and the Debugger
The debugger is looking for advice on how it can/should reuse editors as
users debug a program.
In Eclipse 1.0, the debugger had its own editor reuse mechanism. The
debugger kept track of which editor it had opened, and reused that editor
as the user stepped from source file to source file. If the user changed
the contents of an editor, the debugger would open a new editor (to avoid
prompting for saving changes). This way the debugger reduced editor
pollution caused by stepping/browsing many source files related to the
program under debug.
In Eclipse 2.0, the debugger threw out its custom solution, and migrated
to use the worbench editor reuse threshold. This solution also worked well
(and simplified the debugger's job). However, this support has been
deprecated.
We are looking for advice:
(1) Should we fall back to the custom editor reuse policy?
(2) Is there some support that we can leverage from the workbench?
Thanks,
Darin
