| RE: [platform-ui-dev] Editor Reuse and the Debugger |
I agree with nearly everything written here (it's hard to come up with a single editor management strategy in the current UI, editor pins add another mode), but the solution I'd like to try is somewhat different. I'm thinking about an "editor pane", a tabbed part in the editor area that can contain *any* editor. Instead of reusing editor parts, the UI should "reuse" editor panes. In effect, this would be very similar in use to how tabbed browsing works in Mozilla (and Opera, I guess).
More specifically, an editor pane would be able to change the editor part it contains to display new content opened by the user. In this respect, it would almost be like a web browser window. The workbench UI would not open new editor panes unless the user specifically asked for it (or, depending on a preference, the currently active pane's content was dirty), similar to the "New Window" action in web browsers that can be invoked with keyboard or mouse shortcuts. The fact that an editor part itself may provide the ability to be reused just makes the job of the editor pane easier in case the next input it needs to display can be opened with the editor part currently active.
This strategy gets rid of editor pins, provides a general way to control editors in different perspectives (debug perspective could use a single editor pane to display source) and is friendly to future editor history features by making editor panes the anchor point of editor management (so history becomes a natural addition to editor panes). I think it's also more user friendly compared to current implementation by virtue of being more predictable, if nothing else.
At this point, I have to admit to a certain infatuation for browser-style user interfaces. I think they provide a natural way to keep track of several tasks dependent on each other, and I find myself always missing the functionality they provide in complex applications (and Eclipse certainly is one of them). In my own use, I find that I almost never use more than six or seven editors at a time.
I plan to try out this idea for my navigation patch, and I'll report on how it eventually works out. This being the case, I'd like to hear what folks think about this and people pointing out some obvious usability problem. This might turn out to be a stupid idea, after all.
On the other hand, I find Jared's suggestion of opening a set of editors on releated files at the same time appealing. What would be even more useful is if JDT, for example, was able to automatically determine a set of "related" files for a selection and open them in one shot. Being related might mean being one of the top five classes referred from the selection (itself a class or a method, perhaps), having a "meta" relation (web.xml file for a servlet or home and remote interfaces for an EJB, for instance), being some predetermined number of parents or children away in an inheritance relationship, or some meaningful combination of these. Automatically determining this "related" set would mean all the difference compared to a static working set relationship between editors.
--CK.
-----Original Message-----
From: platform-ui-dev-admin@xxxxxxxxxxx [mailto:platform-ui-dev-admin@xxxxxxxxxxx] On Behalf Of Eduardo_Pereira@xxxxxxx
Sent: Friday, March 22, 2002 12:20 PM
To: platform-ui-dev@xxxxxxxxxxx
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@xxxxxxxxxxx03/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