Community
Participate
Working Groups
Hello. I propose to allow (make it configurable) wrapping tabs in editor in several lines (now it's only one long scrollable line). I mean as other IDE's do (basically I saw 1 line in Eclipse only). Problem with this one line is, that if you have 20 files open simultaneously, you can't see all the tabs at once, you have to scroll first, or open combobox with list of tabs. This means extra mouse clicks and movements, as well as loosing concentration. If all the tabs were visible (in several lines, because 1 line allows too little space) - it'd only 1 mouse click. And filenames displayed on tabs wouldn't be shortened.
See also bug 58868.
*** Bug 72410 has been marked as a duplicate of this bug. ***
*** Bug 72863 has been marked as a duplicate of this bug. ***
*** Bug 73241 has been marked as a duplicate of this bug. ***
*** Bug 70426 has been marked as a duplicate of this bug. ***
*** Bug 42472 has been marked as a duplicate of this bug. ***
*** Bug 78768 has been marked as a duplicate of this bug. ***
Take a look on org.eclipse.ui.examples.presentation plugin (in CVS), this allows wrapped tabs etc. There is also a new bug 93806 for such perspective extensions.
*** Bug 107061 has been marked as a duplicate of this bug. ***
Moving Dougs bugs
*** Bug 172013 has been marked as a duplicate of this bug. ***
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
*** Bug 309358 has been marked as a duplicate of this bug. ***
I know that there are other ways to get the complete list of open files, but they all involve either special keystrokes or using the mouse to drop down a list. I often keep many files open and usually spell out complete words in my file names so they get quite long. It would be much easier for me if all of the open files were somehow visible on the screen at once so that I could go to the desired file with a single click. The way I envision it, this could be achieved with a) multiple lines of tabs, b) having the ability to move the tabs so they paint down the side of the editor vertically rather than horizontally, or c) have a dockable view (like the navigator or package explorer) that has a list of all open files and can switch between them with a click. It might be nice to have the list be alpha ordered, but order of creation would be fine too. The two problems I have with the single line tabs as they currently exist is that 1) when I get too many tabs my long file names often get truncated (and many times the interesting part of the name is what gets truncated, so I have tabs for different files that all look the same) and 2) I can't go directly to the file I want with a single click once I have more than a half a dozen or so files open. Someone did note that it would save some space to optionally get rid of the icon on the tab -- for the work I do, the icon is useless as I know the type of file by its name and extension, and only work with a few types of files anyway. Thank you very much for such a great editor !!
This issue is getting too inconvenient. First, I need to thank the Eclipse teams for providing such a wonderful IDE, whose features used to be inferior to Netbeans but no more. Thank you very much. I would like to add to the conversation that, I am sensing some intransigence from the teams about this issue, and I hope they are not paternalistically telling us how editors should be used. I hope you guys will listen to us about this issue. Please condescend to our needs. Thank you very much for your great efforts in making this wonderful IDE. (Of course, it's wonderful only up to the point why there is such deep disconnect between maven and OSGI despite tycho).
Hi, I also agree. I don't remember the last time that I had less than 10 files open. I also use a dual monitor setup with my Eclipse on my secondary monitor in vertical "portrait" orientation and all the views arranged on the other monitor so I have lots more room for code, but absolutely NO ROOM for tabs. I don't even look at the tabs anymore, they barely contain 3 letters each. Sure ppl can say that one may remove icons, sure there are other ways to access them. Please don't tell me how to use my application. If I want to dedicate 250 vertical pixels to 5 rows of tabs, that should be my prerogative. I think that when every major browser offers this option (see FF+TabMixPlus, see Opera) then there is an obvious mainstream appeal. I think that the "Chrome" approach is totally unsuitable for power users such as those who use Eclipse are. (If the look-n-feel camp is soooo concerned with how it will affect the "eclips-ishness" of Eclipse, then by all means, just ship it off by default. But please include this. Eclipse is one of the most versatile and powerful IDE's available. Please help us by making it more flexible and suitable to our daily needs as well. Thank you for listening to my comments. David Coleman Technical Leader | Union Pacific Railroad
There is more flexibility in how rendering is set up now with the move to Juno. Please comment or help out on bug 58945 and we can consume this. PW
So after years and increasing numbers of requests, I get an email in my inbox saying that this ticket was updated. The milestone has been cleared from 4.4 to "---"... I see that user friendly design is of little importance to the all knowing GODS on the eclipse team. Seriously, how can you justify ignoring this request? How may tabs are open in your IDE right now? I have 55. Our job as developers is not to develop those things that we *like* or *want* but to develop flexible software that gives the USER what THEY NEED. If you don't like/want multi row tabs... don't use them. But I NEED THEM. And a whole lot of other people do too. Please re-consider.
(In reply to David K. Coleman from comment #19) > I see that user friendly design is of little importance to the all knowing > GODS on the eclipse team. > > Seriously, how can you justify ignoring this request? How may tabs are open > in your IDE right now? I have 55. While I can understand your frustration, your drama is self-defeating. As a Technical lead I'm sure you understand resource constraints. The planning was done with that in mind, see the thread http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05493.html > Please re-consider. I'd consider a contribution but AFAICT this bug has been blocked on something it needs to consume, bug 58868. PW
Replay to @ Paul Webster CLA 2013-10-25 11:10:16 EDT "As a Technical lead I'm sure you understand resource constraints. The planning was done with that in mind, see the thread" Oh..please..resource contraints.. You're putting out a bunch of totally unnecessary updates, that just changes the interface making it more and more unusable with each update and other bloatware like Mylyn and useless plugins and forcing it on the users, but a common-sense change, like having MULTIPLE ROW OF TABS IN EDITOR (like IntelliJ IDEA has!) can not be done.
(In reply to Dom Hemingway from comment #21) > > Oh..please..resource contraints.. Yes, that's exactly it. > You're putting out a bunch of totally unnecessary updates, that just changes > the interface making it more and more unusable with each update and other > bloatware like Mylyn Platform UI has nothing to do with Mylyn. You're getting that from another team. and useless plugins and forcing it on the users, but a > common-sense change, like having MULTIPLE ROW OF TABS IN EDITOR (like > IntelliJ IDEA has!) can not be done. It's all about the resources. Planning is done in the open usually in the first 2 months of the summer, so it's done for 4.5. It's all announced on our dev list. See https://wiki.eclipse.org/Platform_UI/Plan/4.5/Planning_Bugs for the state of Mars for Platform UI. PW
I have 4k display with same resolution) without scale to 150 or 200% and I feel uncomfortable when all editor tabs in one line Text in tabs also collapsed(trimmed), and need to press CTRL+E, in 4k display I have a lot of space for tabs as rows, but have no possibility to turn on this for use. Please add multi-line editor tabs support...
