Community
Participate
Working Groups
Hi people, Working & debugging on our medium-size app frequently involves 5 - 8 core files and, as we work patterns through and check related code in other files, an extra 5 - 10 files will get opened. These open files get substantially awkward to manage & navigate; especially in the debugger, which tends to have less screen space. I use Ctrl-Shift-R as a matter of course since the horizontal tabs are effectively useless for my purposes. As an immediate solution I'd like: 1) Ctrl-Shift-R to work in the Debugger 2) option of vertical tabs for the files, so I can clearly see up to 20 Longer term I could imagine having Eclipse automatically track the 'core set' of files which I'm working/ editing closely with; and having a slider which I can pull back to drop the less-core files off my tab list. Would this be helpful for other people? It's about the only area in which I prefer JBuilder :-) Regards, Thomas
You can turn on the "Resource Navigation" (CTRL-Shift-R) commands in the debugger by doing the following: "Window -> Customize Perspective -> Commands (tab) -> select Resource Navigation". Editor management is a workbench issue. Moving to workbench.
Hi Darin/ people; been using Eclipse for several months now, it's a great product, but management of editors is still one of the top 2 limitations. I'm typically working with 5 - 8 files to work in one functional area and reasonably often when interworking two functional areas, and perhaps a controller, I'm actively working 10 - 12 files. With this number of editors open the Eclipse UI just gets stupid. So much space is taken up with 'J' and 'X' icons that all I see is Access..., Access..., Access..., and Exec..., Exec...., Exec... (The class names in this design are named with functional area first). It's not near good enough! Now I always have heaps of white space on the right side of my screen; with an 80 column margin there's probably 140 - 160 pixels doing very little over there. I want the editor tabs vertically, on the right. I already know about Ctrl- Shift-R and Ctrl-Shift-W, they're not sufficient. I want this (significant) usability issue of the Eclipse product, which is one of the biggest, resolved.
Ctrl+Shift+R works in the debugging perspective now. I agree with your impressions of our support for multiple editor and files. I've been thinking of trying to improve the editor management in Eclipse (yet again). Here are some of my ideas; I'd be curious to hear what you think about them. The basic idea is to expand the functionality of the package explorer by adding several top-level nodes, of which the current package explorer functionality would only be one. The idea is then that this view could be docked to the left or right of the editor -- providing vertical tabs on steroids. The tree would contain some or all of these nodes. + \--> Modified Files. These are files that have uncommitted changes (Team/CVS). \--> History. A list of files (possibly grouped into days) and sorted MRU. \--> Working Sets. An area in which working sets can be created; drag'n'drop support for adding files to a working set. \--> Outline. The outline of the currently selected file. \--> Package Explorer. The current package explorer tree. I'd expect the common use case to have the modified files at the top, and perhaps a little bit of the history showing. I believe that most people use "Ctrl+Shift+T" and "Ctrl+Shift+R" to open new files. The concept of opening and closing files would be removed. There would be one active editor, and a cache of recently opened files (to improve performance). The title bar of the editor would display an icon, the name of the file and the maximize button. It might also include a drop-down containing the cache of most-recently accessed files. This is more than you're asking for here, but I am curious for your opinion.
Hi Douglas, Thanks for your comments and interesting ideas, soory about the slow response but I've been getting product out the door. Editors List in the Package Explorer - very impressed by this suggestion, this is a new idea to me and could provide very effective solutions to find files/ editors. Having a distinct set of 'open' files is still important as an organizational concept, but using an 'Editor Explorer' tab see & switch between these would be much more productive. The 'History' and 'CVS Modified' lists would be slightly back from the frontline but would be highly useful when required. These Editor, Modified and History editor/ file lists should probably be a separate tab from the Package Explorer. The Package Explorer and Resource Navigator are for different modalities of use, and the depth of finding files in these is already costly. Indeed I normally have the Heirarchy tab sharing a pane with the Explorer, and visible instead. With the proposed Editor List tab that would share the pane and tend to take precedence over the Heirarchy. So I very much like these ideas but would keep the explorer/s separate, and definitely preserve the 'Open File' organizational concept which really fills a distinct logical need. The idea of History and CVS Modified lists is absolutely great, and these would fit well into a 'Working Files/ Editors' pane. Lastly, Working Sets: it would be nice to be able to select a Working Set into the Navigator etc selection so as to run CVS commit, branch etc operations on a consistently reliable basis. Anyway thanks for your interesting ideas and keep up the good work, Regards, Thomas
These are 2 UI proposals for beter navigating in large workspaces with lot of projects inside: 1. Save tree state: for package explorer add save/restore functions. User can open only sub-trees of project that he wants, and save that state. After he open several other sub-trees, just click to restore and hiss package tree restores to default state. He needs not to collapse-all/reopen-nodes-again all the time. This could be alternative for working sets for people that must look to files outside working set too often. 2. Add "Color" for nodes of package explorer (default: none of course). User can make some projects red, some files green or resources black. Don't save this information to projects however, different users will probably want to set different colors on different nodes.
And one more: 3. Add "Remove from current working set" popup option on right-click to tree-node (or selection of tree-nodes). It is often quite difficult to strip all unneeded nodes from working set using filters only.
These points are all brought up elsewhere, in separate bugs. I would encourage you to check out "http://www.magma.ca/~pollockd/despumate/tabs.html" and add yourself to the CC for bugs you're interested in. In particular, Bug 10941 and Bug 19812.
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
