Re: [platform-ui-dev] Editor Reuse and the Debugger

[Daniel_Megert@xxxxxxx]

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