Community
Participate
Working Groups
DefaultPartPresentation recently added code to arrange the editor tabs in left-to-right order until the tab list is full, in which case it inserts at the end of the visible list. There is also code to rearrange tabs when an invisible editor is selected from the dropdown. This behavior is quite complicated, which makes it hard to keep track of where editors are. It also makes it impossible for the user to arrange the tabs themselves, since Eclipse may subsequently move an editor if it is selected through the dropdown. It would be much simpler if the following changes were made: 1. The tabs always opened in left-to-right order. The window of visible tabs would scroll to show the newly opened editor if it isn't already visible. 2. The editor dropdown always showed editors in the same order that they are shown in the tabs rather than in alphabetical order (although highlighting the currently visible tabs makes sense) 3. In addition to the dropdown, left and right arrows could be shown on either end of the tabs, to indicate to the user that they are looking at a sliding window of tabs.
I have to agree with this sentiment in general. The new editor behaviour is quite frustrating to deal with, so much so that I've given up on the tabs entirely in favour of the unibrow.
I agree. I'm used to arrange tabs for editing purposes, but after some selection from the drop down list, i never find them again in the place where i positioned them. I completely stopped using the drop down list, in favor of "Editor viewer" plugin, that has some shortcomings but at least shows the edited files in their context and doesn't scramble the tabs order. About point 2. of opening comment, i dont't find bad the idea of keeping the drop down list in alphabetical order, when you have many opened editors it makes easier to find the exact file you are looking for, the badness is in the way tabs are rearranged when you select something from the list. Perhaps the selection of the order in which the list is kept could be a selectable option.
Gabriele, have you tried editor pinning? Turn on "Workbench > Editors > Close editors automatically" checkbox, set the number of opened editors to as large as you wish, and now there will be a new menu option on the editor tab to pin it.
I've talked with Nick about this, and it appears that the original intention of the MRU code was as follows: 1. When there is not enough room for all tabs, the most recently used ones are shown. 2. This affects tab visibility but not tab order. The relative order of tabs is never changed. This is a much simpler algorithm than what exists in head, and it seems quite useful. I've attached a patch to bug 72217 that implements this algorithm. Renaming bug: this bug requests the removal of the current MRU tab reordering code. MRU tab visibility is fine.
I think I have submitted the same bug again - 72491, sorry, but I can only say that all my colleagues are annoyed after migrating from 2.1 to 3.0 even because tab order is unpredictable in 3.0. Please think on possibility to turn on/off any implemented "automatic" reordering algorithm (by workbench preferences).
Veronika tells me that CTabFolder will add something that will let us implement MRU tab visibility. The reordering code has been removed from the default presentation in HEAD. This (and bug 72491) can be flagged as fixed. However, this creates a temporary regression (in that there is no MRU visibility) until SWT adds the new behavior.
Fixed in head.
These bugs were modified after M1 had shipped. I'm attaching them to the 3.1 M2 milestone so that they are picked up for the test pass. If they were fixed earlier, please feel free to remove the target milestone.
I200409230800 verified on Windows XP, multimonitor
Hi, thanks for working on this bug - it is better now, but new tab order replacement is still not intuitive. Do you ever used UltraEdit editor? This tool handle multiple tabs exactly so how one would expect. I will try to show you an example how Eclipse handle tabs now. Assume you have "a b c d e f g h i j k l m n" tabs, opened in alphabetical order. Start state: "h i j k l m n" tabs are visible, "a b c d e f g" tabs are hidden. Now you select "d" editor in editor list. Currently tab "h" will be overriden => you will see: "d i j k l m n" tabs are visible. Selection of "a" => "a d i j k l m" tabs are visible. Selection of "h" => "a d h j k l m" tabs are visible. In all cases the tab order is broken, user can't understand where "b" and "c" tabs gone, why "h" tab is placed after "d" and is followed by "j" and not "i". What I would expect: You select "d" editor in editor list => you will see: "d e f g h i j" tabs are visible. Selection of "a" => "a b c d e f g" tabs are visible. Selection of "h" => "h i j k l m n" tabs are visible. The order of tabs should be always the order which user wants, not the order that Eclipse *can* show because of some strange internal calculations. But back to the roots - none of items, reported in comment #1 by Stefan, are implemented: > 1. The tabs always opened in left-to-right order. > The window of visible tabs > would scroll to show the newly opened editor > if it isn't already visible. - not implemented (or still wrong implemented) > 2. The editor dropdown always showed editors > in the same order that they are > shown in the tabs rather than in alphabetical order > (although highlighting the currently visible tabs makes sense) - order in the tab list is ok now, but wrong (even hidden) editor names are highlighted > 3. In addition to the dropdown, left and right > arrows could be shown on either > end of the tabs, to indicate to the user > that they are looking at a sliding window of tabs. - not implemented I wonder why is this bug closed now? Ok, some (good) changes are done, but the main problem still remain.
This bug was closed because the behavior in comment 4 was implemented.
I notice that this bug is open with target milestone 3.1. Does anyone know what the official word is? Will Eclipse go back to a sliding window of tabs (as originally requested), or will it continue to use MRU visibility (as per comment 4)?
Excuse me for this, but i continue to find the way eclipse arranges the editor tabs a nightmare, and i'm not alone. Most of my collegues, coming from Jbuilder and Netbeans, still complain about the fact that when you have more more opened editor than the number of tabs that can fit in the window, finding a particular editor is a real puzzle. I agree that a growing number of tabs in Jbuilder and Netbeans steal useful space from the editor window, but at least you always know where an opened editor tab is, related to the others, it won't move from there and you can retrieve it with a single click. So i'm restating back the requests of opening comment, comment #2 and comment #10.
Unfortunately, I don't believe much or any work will be done on this for 3.1. Priority has been given to the contributions work.
If this is deemed to be correct behavior, the ordering issues can be fixed by removing line 224 of PaneFolder.java: tabFolder.setMRUVisible(true); This won't add the left and right arrows for scrolling the tabs, but it will fix the other issues.
Could any one from UI team remove this *one* code line (comment 15) in the next integration release before M4 is coming out?
*** Bug 83721 has been marked as a duplicate of this bug. ***
Sorry, but we have now M5 release and it seems that nobody will change something on current bug state. Please, change at least the *one* code line (comment 15) in the next integration release. I couldn't believe that this change is too complicated or has too much side effects that UI team is not able to fix it for 3.1 release. Even if you need better argumentation to get time to fix this bug from management, you could use this document: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_1.html "Themes and Priorities": -------------- Simple to Use - The Eclipse platform needs to not only provide the features that advanced users demand, but also be something that most users find simple to use. This theme includes ease-of-use reviews of existing features, and work that helps make Eclipse-based products simple to use for users with widely-varying backgrounds and skill sets. -------------- This tabs behavoir is really weird/not simple to use for *any one*, isn't?
The issue isn't the time it would take to make the change (that's trivial): the issue is that the MRU ordering is considered a feature, not a bug -- and there are people that like it. This is taking awhile because the UI team needs to figure out what the majority of the Eclipse community feels.
Ok, I see. I hope that my opinion is supported by majority of Eclipse community (at least by 100% of my colleagues which are using Eclipse 5 day at week). Another reason to change current behavoir is the opened editors drop-down list, which sort order it the same as for tabs - no one MDI program that I know ever change the order of opened windows in "window" menu. This is not by accident, I think. But why Eclipse should be different??? If it is not possible to completely remove MRU, then probably it is possible to add a option to workspace, which tab order should be used? P.S. Could anybody who knows somebody who like current implementation give me a hint which multipage/multiwindow program has MRU tab/window order? I know that my favorite programs (Ultraedit/Opera/Dreamweaver/Acrobat) doesn't implement MRU - but probably I should use better programs with MRU or another one tabs sort order, so please help me to find these.
Hi all, i completely agree with Andrei. I conducted a rapid survey with my colleagues, we are about 30 developers, half of which already migrated to eclipse, and all of them complained about tab reordering. As i wrote in one of my previous updates all agreed that jbuilder and netbeans use a much more intuitive way to show tabs. One even switched back to netbeans because, her words, "I never know where eclipse decide to hide what i'm editing..." May be someone like this kind of puzzle, so we are not asking to remove it, just make it an option, so that one can decide if he wants to play treasure hunting with the editor tabs or nail them in one place and be sure he'll find them again in the same place.
I see that this bug is currently in a "top-twenty" opened bugs against Platform/ UI component with at least 5 votes. Not bad, but I suggest that all cc-members who has not yet voted for this bug, vote for it *now* and probably get our colleagues to vote. My message for UI Team - don't reinvent the wheel, just add one option to preferences - this is acceptable for all and feasible. The time works against us, but I still hope that we will see some changes in M6 release (1 code line from comment 15 + get/set properties from props page + one checkbox is not really diffucult to implement).
I thought I was going crazy until I stumbled upon this bug report. The MRU thing may look good in theory, and it may have done something nice for me once or twice, but for the most part it just scrambles my editor tabs and causes a lot of confusion. When something like this is bothering a fair amount of people, I'd think it would be a high priority to make turning it off an option.
Just curious does anyone pin editors? (in 3.1) See Window > Preferences > General > Editors - turn on "Close Editors automatically - change the size of the maximum # of open editors if you like - now when an editor is open that should not be transient or closed, click on the pin button (green pin and a small window) and pin it to keep it
I personnaly rarely pin editors. But I fail to see how this can fix the MRU tab ordering problem.
I have tried to use "pinned" editors as workaround (as recommended in comment 3 and now again in comment 24) to the problem "where is my XYZ editor now", but I give it up because this does not solve the main problem. Why one should do extra work (and not forget to do it every time with each opened editor) which could be so easy done by Eclipse itself? I belief and hope in simple theory - that the computer are built for humans and not humans for computer. The case of MRU tabs is the evidence that the exception proves the rule. P.S. We are in the top-ten list of opened bugs for the Platform/UI with at least 10 votes, and in a top-thirty list of opened bugs for the entire Platform component. It is now enough votes to made some work on this bug?
Thanks for trying pinning, and for commenting, I just wanted to get a feel for whether they are useful/used. Are there any opinions about multiple rows of tabs vs left-to-right scrolling? Andrie, voting is important, and the more the better, of course it is only one part of the equation.
I do not think that multi-row tabs is the way to go. This would mean that even less is available to what is actually important - the source code. Currently I think that Eclipse is being hard to use if you get below 1280x1024 in resolution, and even at that resoution you need ClearType to get the most out of it.
I would be in favor of left-to-right scrolling. Or even better, having chevrons (similar to the existing one) on each side of the editor tabs. When you click on the left chevron, it would show the list of editors that would appear if you scrolled left, and symetrically for the right chevron.
I personally have never used pinned editors for normal work. I tried it as per advice in this bug, but it didn't solve the mru ordering problem. About your last question, i think, that it depends on screen real estate. I mean that with small screens having a single scrollable tabs line has its advantages, while with large screens having multiple rows has the advantage that you can immediately locate your editor without too many clicks. As i said in one of my previous updates there are fans of multiple tab rows, i even saw people working in jbuilder with 3/4 tab rows on 15" screens, and i heard many commplaining after switching from jbuilder/netbeans, about not being able to see all the opened editors at once. So if that is not too much work for you :), you could chose the catch all solution that makes everybody happy: tree options: 1- single tabs line, mru ordering for masochists (the code is already there) 2- single tabs, left/right scrollable, line 3- multiple tabs lines, jbuilder/netbeans like style (here's where limiting the number of opended editors and pinning could become useful) (personally, since i work on a 1600x1200 pixels screen, i would welcome option 3) All the three modes should allow for tabs repositioning by cut and paste like now. Gabriele.
I think that the option for N rows of tabs is not a bad one. I think I would use it. There are maybe some small things that can incrementally improve "time to find a resource" As more tabs are added and it is time to shrink the size of various tabs, it would be nice if it was smart enough to start dropping the fileName extension first. It seems one can visually pick out the resource quickly without the extension especially since there is a icon indicating what type of resource is it. The tooltip delay when hovering on a tab should be near 0
I think comment #30 would be an acceptable solution (actial any thing else than mru would be great). In addition I would like to have the drop-down list of editors sorted alphabeticly so I would have two ways to navigate: by possition using the left/right arrows and by name using the drop-down box. But whatever the solution would be please give an alternative to the mru ordering!!!! At the moment I have disabled the tabs at all and using the EditorView plugin.
A couple of things. Guido, i use a lot EditorViewer plugin too, so i opened bug 63802 to request it or something similar to be integrated into eclipse base. If you are interested you could vote for it. Then, in the last line of comment 30 i didn'n really mean "cut an paste", but "drag and drop".
Thank you for all of your input and suggestions. Personally, I'm not a huge fan of the MRU ordering either. I believe it is partly inspired by editor management in IntelliJ. Unfortunately, the Platform/UI team is having problems coming to consensus on this bug, and we don't have a lot of time left for 3.1. We don't feel that it is appropriate to make this kind of change at this point. If, for example, a large number of people like MRU ordering, we would not find out until 3.1 has almost shipped.
This is a strange argumentation. - This bug is 9 month old so there should be enough time to discuss it. - I don't see any voice who likes the mru. - Where is the problem to make it configurable? This would mkae everyone happy.
Hi Douglas, you wrote in comment 34: > Unfortunately, the Platform/UI team is having problems coming to consensus on > this bug This is a very good reason to make this MRU behavoir optional - if one don't like it, one could turn it off and vice versa. You could not say that one additional preference for this behavoir is very difficult to implement or to test or whatever. I swear that the time which the UI Team have spent on talking about/reading/writing comments to this bug exceed the time to fix and to test it. > If, for example, a large number of people like MRU ordering, > we would not find out until 3.1 has almost shipped. If the MRU behavoir will be "optional and default", then no one who like it will miss it if it will be shipped with 3.1. But again, as noticed by Guido, I haven't seen any one who likes MRU. Not here, not on my work, not in any newsgroup or forum. Please give me one reason for the current behavoir. Cince my comment 20 no one has pointed me on similar "feature" in other programs. This is probably because this MRU is not a feature at all? In comment 18 I have pointed you to the Eclipse 3.1 project plan - remember: > Simple to Use - The Eclipse platform needs to not only provide the > features that advanced users demand, but also be something that most > users find simple to use. We see here again that the current implementation could not fit even to already existing 3.1 roadmap. This is a bug, and not a feature, and should be fixed as soon as possible, *before* 3.1 final.
Just a minor observation. One thing to make thing easier is to have things in predictable places. To me this means that these tabs should either be in the order that they were opened, or sorted alplabetically.
I think the Eclipse team is risking losing power users over this. When championing Eclipse at work I made a point of how responsive the team is to what the community wants. And now there's something floating around here for 9 months and the team's response is "We don't feel that it is appropriate to make this kind of change at this point." Most of the people commenting on this bug, at least lately, have been in favor of leaving it on by default, and providing an option to turn it off. Its not appropriate to make that kind of change?
IMHO, the window shuffling feature is one of the most annoying ones currently present in Eclipse. It's a productivity killer. Please, give us a means to turn it off. Thorbjørn Ravn Andersen's solution would be great.
The main argument for keeping the status quo has been that there may be a silent majority in favor of the current MRU behavior. This is hard to disprove because bugzilla voting only attracts those who dislike the status quo, and bugs like this tend to attract votes due to their visibility rather than their merit. I believe that PRs like this justify having some sort of voting both on the main Eclipse page, where Eclipse comitters could offer the most contravercial issues for the community to decide. By announcing each issue on the newsgroup and making them visible to everyone, it would be easy to get a feel for what the community as a whole thinks and address the issues faster.
I agree with that sentiment. I filed Bug 88804.
See bug 79225
I'm sorry, but i don't understand where is the problem. If you are talking about resource shortage to implemet a solution to this, then this is a real problem, otherwhise, if you read carefully this bug, nobody is asking to throw away what you have done, just to make it optional so that the "silent majority", if it exists, can continue to work undisturbed in the same way, but we can chose what best fits our needs and our way of working. That way of managing editor tabs is one of the worst i've ever seen and this opinion is shared by all the people in my group (about 30) that gave a try or switched to eclipse. NO ONE likes it, even if i'm the only one that takes the effort to cooperate with you testing milestones and reporting back. Someone said "I think the Eclipse team is risking losing power users over this" and i can assure this is true, in one of my previous updates i reported about a girl going back to netbeans for this reason, and last week i've seen another guy that gave up for the same reason. As one of the famous IBM motto says, "THINK"...
I voted for it. Whatever algorithm it's using in 3.1M5a is non-intuitive. I can't predict which tabs are going to get removed if I have a limit set, or what the next/prev editor/view is going to do. I've tried pinning but it wasn't a satisfactory solution. Most of the time I'm suprised by what it's doing. I'm not sure what algorithm other editors and ides use but I don't recall being suprised by them.
I added my vote to the list. I really don't understand the rational for not at least making this configurable. I use WSAD at work, and Eclipse 3.01 at home. While most things are a huge improvement over the 2.x series, this one just doesn't make any sense. Anybody who has more than 10 windows open, quickly becomes lost with the MRU algorithm. One other point that makes me question the MRU feature. Eclipse allows tab drag and drop for placement, but then it moves it if I edit another file. So if you let me place the window, what makes you think I want it moved again the next time I open a file? I would be surpised to find anybody who frequently has large numbers of open files that actually finds this feature useful. If you want a good example of properly handled tabs (and configuration of them), take a look at the Tab Mix plugin for FireFox. I especially like the "Scrollable tab bar with buttons" option.
As a bug 79225 is even not yet assigned to anyone, I have placed a nice poster dedicated to this bug on my homepage ;) http://andrei.gmxhome.de/eclipseMRUbug.html
And because the poll infrastructure is still not there, I have posted a message to the JavaLobby forum: http://www.javalobby.org/java/forums/t17967 Your are welcome to participate in the discussion.
A left-oldest ordering scheme (like every other editor, even tabs on browsers) would be much more intuitive. Why? It's simple. It allows for predictable tabbing between panes. It does not distract from code editing, thought and discussion. The MRU makes it very difficult to pair-program, and display portions of the code to another person. It should be left-oldest or at least configurable. In this example, max number of tabs visible is 3. numbers indicate the order in which files were opened. 1 2 3 open file << 2 3 4 (4 is visible, 1 is reachable through button/menu "<<") return to one 1 2 3 >> (1 is visible, 4 reachable via menu ">>") The menu produced should be in left-oldest OR asciibetical order: 1 2 3 >> | 4 5 6
Currently I can't use tabs, instead of tabs I use ctrl+e to see the editor drop- down list. I have just noticed the existence of bug 75376 - it seems that this list doesn't show the full file path in Eclipse 3.1. If so, how useful will be editor management in Eclipse 3.1? There are 127 bugs (+98 rfc's) with [EditorMgmt] in bugzilla, so I think that the UI Team should increase the priority/severity for this and many other [EditorMgmt] bugs for 3.1.
The priority of this bug was changed, but not from P2 to P1 - it was changed to P3 - that means, that this bug is not more targeted for the 3.1 final release (http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/eclipse-project-home/plans/ 3_1/freeze_plan.html). Furthermore, as I can understand, P3 means that this bug will be never fixed (currently there are 6500 opened P3 bugs but only 227 P2 against [Platform] and 2394/87 against [Platform/UI]). This is very angry... @Stefan Xenos: in your comment 15 you wrote about removing "tabFolder. setMRUVisible(true);" line in the PaneFolder.java. Is this still correct - or do I need more work to fix "auto-reorder" behavoir? Could you also point me where in the code of the current 3.0 release is this "feature" (I couldn't find PaneFolder class)? I think I would simply recompile the appropriate component for me, and then share it between my co-workers.
There was a request by the Platform/UI team lead that all bugs not targeted for 3.1 be moved to P3 or lower. This does not mean that this bug will not be fixed. In fact, I would like editor tabs to be one of the top priorities for 3.2.
re: comment 50 Grab org.eclipse.ui.workbench from CVS and use ctrl-shift-t to find PaneFolder. If you're willing to hack some source, you may get more just installing the org.eclipse.ui.examples.presentation plugin (in CVS). That will also add experimental options for wrapped tabs, vertically stacked tabs, icons-only, and others.
@stefan: Thanks! I have checked out the R3.0.2 branch from org.eclipse.ui.workbench, but the "setMRUVisible" method call seems to be introduced first in the 3.1 branch (it was introduced in the 1.23 revision of PaneFolder, R3.0.2 is based on 1.19 revision). Because I'm working mainly with 3.0.2 release, I woould like to try first the 3.0.2 "hack". I saw that the change with "setMRUVisible" call was done by fixing the bug 72217 in the CTabFolder, but the MRU behavoir was already existing before, but where? Where I could find the 3.0.2 code for the "MRU"?
Perhaps if someone fixes this they could post the patch to this bug, so that others may share? Thanks!
It was a lot of work getting it to the point where it could be easily turned off. Removing it in 3.0.2 pretty much involves rewriting the default presentation. Use 3.1... or just install the presentation examples plugin.
The wrapped tabs example presentation is kind of nice; with a little polish it could be quite useful. I like the way it puts a list of all views/editors on the part's system menu but I don't like the way it handles the view menu. The native tabs one always puts tabs at the bottom no matter what I do, and all the toolbar icons are very tiny, but I'm not up to date with the latest 3.1 build so that could be it. Tab ordering and automatic closure should probably be done through some kind of strategy pattern so presentations could pick and choose which one they wanted to use.
This is getting a bit off-topic. I've filed bug 93806 to discuss custom presentation changes. I would encourage anyone that wants to hack the tab ordering code to participate there. Since this is an example plugin, it's easier to incorporate experimental ideas there without getting bogged down in the usual usability debates.
To Stafan - thanks a lot, the examples plugin is a very good one. Like Ed, I wish some polish to the themes, but wrapped tabs and *not* MRU should be really default. If this plugin will be a part of the official release, then you can simply close the current bug, because no one will then use the "default" presentation, and with it, this bug will be obsolete.
Re: comment 58 If you'd like to help with the polish of the new themes, please contribute patches in bug 93806.
To comment 54 - I have made a small fix for Eclipse 3.1 M7/RC0. This is a slightly modified org.eclipse.ui.examples.presentation plugin from Eclipse CVS repository. I have added the "MRU fixed default presentation" to it, added some preferences to the "wrapped tabs" presentation ("Window->Apearance->Wrapped Tabs", restart required) and removed some unusable presentations. "MRU fixed default presentation" is the 1:1 copy of the default 3.0 presentation but with "setMRUVisible()" flag turned off. You can download it from my homepage (both sources and binary): http://andrei.gmxhome.de/mru/org.eclipse.ui.examples.presentation_1.0.8.zip
Anybody knows if there are plans for 3.2? P.S. To comment 60 - I have removed the code bacause of some issues with non-MRU behavoir in the other UI parts. Please check the another presentation at http://sourceforge.net/projects/eclipse-skins or the similar one at http:// andrei.gmxhome.de/skins/index.html
Since this is an easy thing to turn on and off with CTabFolder (just one method call which can be done any time during the life of the widget) why don't you consider making this a preference? A significant number of people are requesting it. I see this has been mentioned by others in this bug report but I am raising it again.
While investigating: removing the call has the effect that now when dragging tabs around the new order is not remembered on restart, this is a little more complicated then just commenting out the setMRUVisible call. See also bug 100993
Doug has left, this is not on the plan for 3.2 any longer.
Some work is being done on this... check out bug 168379. It's work in progress, but I already like it a lot. Please add flames to this bug and constructive comments to bug 168379. ;)
For those watching this bug there is an excellent plugin "Extended VS Presentation" (http://andrei.gmxhome.de/skins/index.html) which among other things removes the MRU ordering.
Another possibility is the auto-pin tweaklet from our incubator update site - try entering [1] as the URL for an external update site (Help > Software Updates > Find and Install, select "Search for new", click Next, then "New Remote Site"). [1] http://www.eclipse.org/eclipse/platform-ui/updates
Re: comment 67 It's good to see progress being made on this front. The tweaklet looks quite promising. Well done. However, it looks to me as though the tweaklet (which is lovely - thanks) would still work nicely without MRU. Re: comment 63 I see tab order getting lost in exactly the same situations with MRU ordering as without, and (looking at the code) I see no reason why turning off the MRU ordering would cause the described problem. I suspect Michael turned off MRU, tested various scenarios, discovered one of the several known drag & drop bugs, and assumed it was related to the MRU change. Without steps to reproduce it's hard to tell for sure, but I suspect the problem would have also happened with MRU on.
I just want to "vote" for an UltraEdit-like stacked tabs presentation. This is one of the main reasons (if not THE main reason) I continue to pay for UltraEdit in preference to other free editors. It's also a great editor, but the stacked tabs are awesome. My argument is simple. In any production environment I find code bodies are large. I often find myself with 20-30 or more files open at once. Scrolling back and forth in such a situation is awful. I just want to see all of the tabs and I want them readable. Stacked tabs is the only way I've seen this work well. Download an evaluation copy of UltraEdit and look at how it works. When the tab bar fills up you get the left/right scrolling behavior. If you then pull the tab bar lower edge down it opens up with more rows and the scrolling behavior goes away until you fill it up again. This seems like the best of both worlds. You get the scrolling behavior that many people seem to like and the stacked row behavior that a few malcontents such as myself want. You just lose the MRU re-ordering behavior. Too bad.
(In reply to comment #69) How does UltraEdit solve the problems described by Peter Kasting at [1]? Does it not bother you that tabs move around quite drastically when you close an editor? What happens when you activate a tab on one of the upper rows, does UltraEdit swap rows? If it does, how do you remember which tab is where? If it does not swap rows, how does UltraEdit solve the UI design problem of visually associating the active tab with the editing area? [1] http://www.humanized.com/weblog/2007/06/19/humanized_puzzler_2_firefox_tabs/#comment-31356
When an editor is closed the tabs close up. If there are multiple rows this does involve some tabs moving from the beginning of one row to the end of another. If you select an editor from a row that is not at the bottom the rows do reorder. The order of rows changes sometimes, but seems to be LRU at the bottom. These things annoy me sometimes but overall the experience is better than any of the other alternatives I've tried. I arrange the tabs in an order and they stay in that order (row re-ordering not-withstanding). I can always find them quickly. None of them mysteriously vanish and they are always visible. I suppose that some tweaks could be made to the way that works. Having a matrix of rows that stayed stable and showing the chosen editor by a depressed button (or some such) instead of moving the row down might be better, but the closing re-ordering would still happen just as it does with a single strip of tabs. Personal preference, of course, but the fact that leaving only one row visible degrades gracefully to a left/right scrolling strip of tabs seems like a beautiful way to provide two options in the same control. I urge anyone running Windows to download the evaluation copy and play with it. Over the years I've made a lot of converts. ;)
Hi all, long time has passed since my last update, it looks like it would take less to obtain a UN resolution against a member state than to get rid of that MRU ordering :) Anyway, IMO one of the best SWIPY (Stay Where I Put You) ordering i've seen is that of "Tab Mix Plus" plugin of Firefox. If you don't know it, give it a try, i couldn't use Firefox without it. With it you can choose (the options list is not complete, it reports only the most important points): 1- the min and max size of the tab 2- the highlight options (font and font color) 3- the tab ordering (single row with scrolling [Buttons/no buttons], Multiple rows 4- in case of multiple rows, how many of them must be displayed as max (if there are more, two buttons to scroll the rows up and down appears 5- where tab rows must show, top or bottom 6- you can decide where the next opening tab will appear (next to current one or last) 7- which tab gets the focus when you close another one 8- you can customize the depth of undo close tab list 9- you have a button that shows the opened tab list 10- tabs are managed as a long list so when you close one all subsequent tabs packs on left 11- you can move tabs in a row or between rows and they WILL STAY THERE until you close them (tabs pack on left only when you close one, otherwise they'll never change relative positions unless you voluntarily move them) 12- when you click on a tab, nothing moves, the tab is simply highlighted to show it is the one active 13- you have a highly customizable and very rich tab context menu (mouse right click) 14- mouse behavior on tabs is customizable Should i continue? That's the model i find most intuitive and i'd like eclipse introduce as tab ordering OPTION. In a few words even with 30/40 opened tabs i'm able to find the one i need in one or two clicks and one or two seconds of time. Can someone tell me when you are editing the same amount of classes (too many you say? It happens, it does happen!) in eclipse how long does it takes to hunt back an editor tab you opened, lets say yesterday? I don't know how your brain is working, i'm a limited human being, so mine works like an associative engine and relative place and surrounding things helps me to remember where i put what and to retrieve it. With MRU playing magic sometimes it takes me longer than 10 seconds and a lot of pain. That MRU thing remembers me the times, when i was student, that getting back from school mommy said me "Your room was a mess, i reordered it". That were real strikes of terror because i knew it would took a week to recover back things from her concept of order to mine. Pls don't do as M*oft that says let me take care of you because i know best than you what you may ever need or wish. I'm not telling MRU is bad, there are so many ways to kill themselves that i'm sure you can find somewhere one or two people that may like it :) I'm only saying it's not working for my brain, and as far as i can see i'm not alone. Someone may prefer Potassium Cyanide because it's faster and cleaner, someone may prefer a machine gun because they also want to decorate room walls with their blood. There's no better option, just give us the options so we can choose the one that fits best our way of thinking. Sorry for the looong update, i'm using eclipse since its birth and this is the ONLY thing that still hurts me. Gabriele
(In reply to comment #72) > long time has passed since my last update, it looks like it would take less to > obtain a UN resolution against a member state than to get rid of that MRU > ordering :) Very true. :-D > Anyway, IMO one of the best SWIPY (Stay Where I Put You) ordering i've seen is > that of "Tab Mix Plus" plugin of Firefox. If you don't know it, give it a try, > i couldn't use Firefox without it. I'll give it a try. > With it you can choose (the options list is not complete, it reports only the > most important points): > 1- the min and max size of the tab ... > 14- mouse behavior on tabs is customizable However, I am not a big fan of preferences [1]. What options did you choose and why? > That MRU thing remembers me the times, when i was student, that getting back > from school mommy said me "Your room was a mess, i reordered it". That were > real strikes of terror because i knew it would took a week to recover back > things from her concept of order to mine. Good analogy, it explains why some users are so annoyed by the MRU logic, while others just accept it. For some, it seems preferable to have someone else bring order into their messes over having to deal with it themselves. > I'm not telling MRU is bad I believe MRU is bad, but I haven't been able to convince all the other UN member countries of it. > There's no better option, just give us the options so we can choose the one > that fits best our way of thinking. The best we can offer right now is the auto-pin tweaklet (see comment 67) - it gets rid of the MRU logic. If you have ideas for improving it, please file separate bugs. If you have an idea for how to manage tabs differently, please read [2] and the Aza Raskin's blog posting it references. After that, if you still think your idea is valid, enter a new bug. :-) That said, we don't have the resources to solve this for 3.4. If someone else would like to try, we would be happy to help as best as we can, but they would have to drive this. [1] http://ometer.com/free-software-ui.html (scroll down to the section called "The Question Of Preferences") [2] http://borisoneclipse.blogspot.com/2007/07/why-improving-editor-tabs-is-hard.html
Created attachment 82095 [details] TabMix plus user options Hi Boris, as per your request i attached the tabmix options that i changed from default. You can see that out of more than 170 options i changed only 26 of them from default to suit my needs. (you can see the difference between defaults and changed options entering about:config in the bar field and filtering content for tabmix) Most are cosmetic changes to make active tab more visible, then i changed the minimum tab width so that when shrinked they always show enough of the title to understand what they contain. I changed the behaviour of where the next opened tab will display and where the focus must go after i close a tab. The rest are about session saving that is OOT here. I'd really wish to have the same tabs functions in eclipse... I think that, to remain on the topic, what makes this extension so wonderful is the absolute sense of control and predictability that gives me about what i'm doing. I can arrange things so that with tenth of opened tabs i ALWAYS can see at first look where things are and have them available at a glance. And things are PREDICTABLE, when i close a tab the right ones pack on right but their relative positions NEVER change unless i EXPLICITLY do it. I can group together related elements an can be sure that they ALWAYS will maintain the relation i created between them. That's exactly what hurts me in the MRU behaviour, the LOSS of CONFIDENCE on the system. Tabs relative positions are always changing and i'm never sure of where and when eclipse decide to hide or move some tabs. May be i'm stupid but this hurts me so much that when i have many opened editors i often prefer to find opened objects in package explorer instead of going through the alphabetic list that pops out clicking on the chevron. The secret Boris is Context. I'm sometimes involved in checking others code rather than write it myself and when i'm trying to figure out how something i didn't write works i end often with tenth of opened editor and sometimes i even don't remember well the name of the opened object i'm looking for, but package explorer gives me a fixed context in which i can find back what i'm looking while editor tabs behaviour makes me completely lost. To be really useful an instrument must keep the pace of your thinking. If you have to disrupt the flow of your thoughts to remind how to use the instrument even for its basic usage, and this even after years of usage, in my opinion there's something wrong with the instrument... I hope you can figure out from my screwed up english the sense of what i mean. Regards, Gabriele
(In reply to comment #74) > are PREDICTABLE, when i close a tab the right ones pack on right but their Sorry the above shoud read: when i close a tab the right ones pack on left
No need to shout - you are preaching to the choir. I agree that predictability is very important. I'll give it a try in Firefox.
Since 3.4 is out I thought I'd try and bring this issue back for 3.5. To me, Tab Mix Plus offers the best tab management. Any of the options suggesting that would be great. Failing that, what about including the work of Andrei Loskutov? His "Extended VS Presentation" plugin (http://andrei.gmxhome.de/eclipse.html) is the only thing that makes Eclipse editing usable. Add a few features to that, give it the default look and feel, and you would probably make most of the people happy. You could even leave it as a different presentation style they way he has it now.
*** Bug 269791 has been marked as a duplicate of this bug. ***
From that bug: "This is caused by the infamous MRU logic which drives me nuts as well, but realistically, will not be changed in the 3.x stream." This bug is now open almost 5 years. Could someone explain to me, why it is so difficult to add a simple checkbox to turn off that behaviour?
When this bug was posted, the creator of the report suggested an excellent, useful, intuitive, sand algorithm for displaying tabs in the editor. 4 years later, I still want to throw my laptop out the window and punch myself in the face every time I close a tab in Eclipse. There are hundreds of applications out there that use tabbed windows for various purposes, and every one of them behaves in a sane and useful manner. Except for Eclipse. I have no idea why. What's the deal with the crappy tab reordering? Nobody likes it, and it's weird, unusual, and 100% counter-intuitive and useless. How is it possible that it's still around, especially given all of the above comments? And who put that there in the first place? *Smack*
Here is a simple algorithm that might work and wouldn't require the addition of a sliding window: 1. When new editor is opened, add tab to left. 2. When visible tab is made active, DO NOT MOVE IT. 3. When offscreen tab is made active, move it to left. 4. When tab is closed, remove it. Do not reorder. In other words, all new tabs are added to left, and the only reordering that occurs is when an invisible tab is made active -- it is moved to the left.
To those who would like to work on better solutions than the current MRU behaviour: Have a look at the class TabBehaviour, which is our non-API "tweaklet" hook for how the tabs behave. I am totally open to adding more hook methods to that class if you need more, at the moment it contains the hooks I needed for implementing the auto-pin tweaklet referenced in comment 67. In open source, code speaks. Contact me on http://wiki.eclipse.org/IRC if you need help. http://wiki.eclipse.org/Platform_UI/How_to_Contribute
I'm using this: http://andrei.gmxhome.de/skins/index.html Otherwise I would have gone mad years ago.
BTW, don't miss to check the extra page and nice posters I've contributed to spread the word about this bug: http://andrei.gmxhome.de/eclipseMRUbug.html http://andrei.gmxhome.de/mru/bug68684.jpg http://andrei.gmxhome.de/mru/bug68684_1.jpg http://andrei.gmxhome.de/mru/bug68684_2.jpg Anyway, I do not use default presentation since years ONLY because of this bug...
(In reply to comment #82) > To those who would like to work on better solutions than the current MRU > behaviour: > > Have a look at the class TabBehaviour, which is our non-API "tweaklet" hook for > how the tabs behave. I am totally open to adding more hook methods to that > class if you need more, at the moment it contains the hooks I needed for > implementing the auto-pin tweaklet referenced in comment 67. I would love to have a look at this when I have time, but realistically that may not be for a few weeks/months. If somebody else decides to take a stab at it in the mean time, please post a comment here. No sense having 5 different people work on it at once.
(In reply to comment #82) > To those who would like to work on better solutions than the current MRU > behaviour: Sorry, but I don't understand. Why would anyone need to look at this and what would this accomplish? The problem is not shortage of resources nor the availibility of fixes, but the unwillingness of the people in charge to do anything about this. It's a feature, remember? So as long on no member of the powers that be steps forward and acknowledges that this is a bug that needs to be fixed, it's a complete waste of time for anyone to look at any source code. As long as the silent majority of Eclipse users likes this behaviour, there is nothing we can do about it...
(In reply to comment #86) > Sorry, but I don't understand. Why would anyone need to look at this and what > would this accomplish? I was just pointing out that there is a mechanism for experimenting with different approaches that can be shared with others, in the form of a "tweaklet" plugin that changes the internal implementation for something like the tab management. The idea is that a plug-in that can be installed using p2, or put into the dropins folder, is a better vehicle for trying to find a better solution than a patch, because it can be shared with others. > The problem is not shortage of resources nor the > availibility of fixes, but the unwillingness of the people in charge to do > anything about this. It's a feature, remember? So as long on no member of the > powers that be steps forward and acknowledges that this is a bug that needs to > be fixed, it's a complete waste of time for anyone to look at any source code. I tend to disagree. This is all about investing the time to produce a product-quality alternative that can be shipped as part of the Eclipse platform. In the past, the only way to do this from the "outside" was to work with patches, or to write a custom presentation, which is a *lot* of work and hard to get right. Hats off to Andrei for writing such a custom presentation. > As long as the silent majority of Eclipse users likes this behaviour, there is > nothing we can do about it... There are indeed two groups: one group that has learned to live with the MRU ordering (or even likes it), and another group that finds it hard to keep track of where their editors are. This does not mean that nothing can be done about it. If the only way to make progress on this issue is introducing a preference, then I am willing to add one more thing to our already crowded preference pages. This bug has lots of suggestions for how the editor tabs should be managed. At this point, I am asking for code contributions that implement these suggestions rather than more comments on this bug. Btw, I don't think the one-line fix as suggested in comment 15 is complete. At least issue (2) from comment 0 would have to be implemented, and ideally issue (3) as well.
(In reply to comment #87) Hi Boris, sorry, I didn't want to start a long discussion or anything. I understand what you are saying, > I tend to disagree. This is all about investing the time to produce a > product-quality alternative that can be shipped as part of the Eclipse > platform. I tend to disagree. :) This is all about getting rid of that annoying MRU reordering behaviour. Everything else is a nice_to_have. While investigating better strategies at tab management is certainly a good and interesting idea, at the moment we are in a situation, where almost any algorithm which turns off MRU would be huge improvement for the user experience. So all I'm asking for, don't delay this any further by looking for that great solution, just turn off this darn thing, and THEN we can talk about the great solution to come. > .... This does not mean that nothing can be done about > it. If the only way to make progress on this issue is introducing a preference, > then I am willing to add one more thing to our already crowded preference > pages. Yes, please! That little change would make a lot of people here very happy! It's what I have been waiting for for several years now. And I bet I'm not alone. Just a little checkbox which gives us the pre 3.0 tab behaviour. Or Andrei's behaviour. Or any behaviour, I don't care. > This bug has lots of suggestions for how the editor tabs should be managed. At > this point, I am asking for code contributions that implement these suggestions > rather than more comments on this bug. Thats great. I absolutely encourage people to work on this. But first introduce that checkbox! Marc
(In reply to comment #87) Hi Boris, sorry, I didn't want to start a long discussion or anything. I understand what you are saying, but, well, I have different priorities :) > I tend to disagree. This is all about investing the time to produce a > product-quality alternative that can be shipped as part of the Eclipse > platform. I tend to disagree. :) This is all about getting rid of that annoying MRU reordering behaviour. Everything else is a nice_to_have. While investigating better strategies at tab management is certainly a good and interesting idea, at the moment we are in a situation, where almost any algorithm which turns off MRU would be huge improvement for the user experience. So all I'm asking for, don't delay this any further by looking for that great solution, just turn off this darn thing, and THEN we can talk about the great solution to come. > .... This does not mean that nothing can be done about > it. If the only way to make progress on this issue is introducing a preference, > then I am willing to add one more thing to our already crowded preference > pages. Yes, please! That little change would make a lot of people here very happy! It's what I have been waiting for for several years now. And I bet I'm not alone. Just a little checkbox which gives us the pre 3.0 tab behaviour. Or Andrei's behaviour. Or any behaviour, I don't care. > This bug has lots of suggestions for how the editor tabs should be managed. At > this point, I am asking for code contributions that implement these suggestions > rather than more comments on this bug. Thats great. I absolutely encourage people to work on this. But first introduce that checkbox! Marc
I tend to agree with Marc. :-) Why have all the people annoyed by the current unpredictable MRU behavior to wait for some Great Solution in unforeseeable future if a simple solution is available and can be implemented right now? Adding a check box in the preferences now does not prevent you to integrate the Great Solution later, and it also does not change anything for people who might like the MRU.
A checkbox for what? The current behavior is simply broken. Jeez, you people are grumpy. I've never worked with the Eclipse code before but I'll take it upon myself to futz around with the Great Solution (TM) if nobody else has touched it. It will take me a while to get to it though.
+1 for the checkbox in Eclipse 3.5 and a full refactoring in e4 with proper user feed-back.
Finally we are getting somewhere! We still need a label for that checkbox. I vote for "Enable confusing, random and completely unpredictable reordering of editor tabs whenever I least expect it". And it's enabled by default, to not confuse people :) (btw, sorry for my last double post)
How about "Disable Sanity"?
If all you want is the no MRU behaviour, and the alphabetical sorting in the dropdown when there are too many editors does not bother you: Use http://www.eclipse.org/eclipse/platform-ui/updates as the update site, and select the "No MRU Tabs Tweaklet" feature. Make sure you restart, I don't think this will work without a restart. I haven't tested it but it should work with 3.4 and 3.5 builds of Eclipse.
Couldn't install the Tweaklet: An error occurred while collecting items to be installed Problems downloading artifact: osgi.bundle,org.eclipse.ui.tweaklets.nomrutabs,0.9.0.200903311244. Exception connecting to http://www.eclipse.org/eclipse/platform-ui/updates/plugins/org.eclipse.ui.tweaklets.nomrutabs_0.9.0.200903311244.jar. http://www.eclipse.org/eclipse/platform-ui/updates/plugins/org.eclipse.ui.tweaklets.nomrutabs_0.9.0.200903311244.jar Exception connecting to http://www.eclipse.org/eclipse/platform-ui/updates/plugins/org.eclipse.ui.tweaklets.nomrutabs_0.9.0.200903311244.jar. http://www.eclipse.org/eclipse/platform-ui/updates/plugins/org.eclipse.ui.tweaklets.nomrutabs_0.9.0.200903311244.jar Error closing the output stream for org.eclipse.ui.tweaklets.nomrutabs.feature/org.eclipse.update.feature/0.9.0.200903311244 on repository file:/Users/vivo/dev/eclipse/eclipse-3.4-jee/eclipse/. Error unzipping /tmp/org.eclipse.ui.tweaklets.nomrutabs.feature_0.9.0.20090331124420670.jar: Invalid zip file format
The tweaklet worked for me (Eclipse 3.4 with latest updates), thanks for pointing that out. The behavior is much better with this plugin. The most important thing is that it's predictable now! However, the alphabetical sorting order in the drop-down window isn't very useful. IMO the sorting order should correspond to the tab placement order.
@Victor - can you try again? I re-built the plugin and feature with minor changes. It could also have been a bad HTTP connection. @Vlad - good to hear that it worked for you. @all - I am looking forward to your contributions. Dropdown in visual order, anyone?
(In reply to comment #95) > If all you want is the no MRU behaviour, and the alphabetical sorting in the > dropdown when there are too many editors does not bother you: Use > http://www.eclipse.org/eclipse/platform-ui/updates as the update site, .... Somehow I knew this would happen. And I thought we are making some progress here... I obviously know about this plugin. And Andrei's, and I am quite happy with it. Its the first thing I install whenever I install Eclipse. But this is not about me. It's about Eclipse users, who don't have the time to hunt around for bug reports and thirdparty plugins to turn off a behaviour which shouldn't be there in the first place. That's why I want a nice little checkbox in the Editor section of the preferences, which everybody can find easily. That's about it. I don't know what more to write. If anything is still unclear, please ask, and I will try to explain. Again. Or I will start to cry.
(In reply to comment #99) > Or I will start to cry. Let's not go there. :-) We seem to agree that we do care about the usability of Eclipse, otherwise this discussion would have died down already. We also agree that there is a group of users who rely on stable visual order of UI elements, for which the MRU tab visibility logic does not work. A while ago I thought I had a solution (implemented in the form of the "auto-pin tweaklet"), but it was perhaps too radical a change, and I ran out of time and energy to push it further. See bug 168379 for details. So two years later, the discussion flares up again. Whining on both sides: I complain about an utter lack of code contributions which we could try out and discuss, and a vocal group of people want a simple checkbox now, or else...! The problem is that unfortunately, with a code base like Eclipse's, it is never just a simple checkbox and one line of changed code. Any feature change introduces or uncovers bugs, and leads to logical next feature requests like the one from comment 97 for visual order instead of alphabetical sorting in the drop down. I spent half an hour implementing the visual order in the drop down, but need help finding the following two bugs when just turning off the MRU tab visibility: 1. The visible tabs after shutdown and restart are wrong - some of the MRU logic seems to be hard coded somewhere. 2. Sometimes you will end up in a state where the current active tab is not showing at all. I was able to reproduce this by Ctrl-clicking on class names several times. If someone can track down the two bugs I mentioned (hoping that these are the only two), we can put the checkbox in. I hope you understand why I cannot just add the checkbox without adressing the bugs and declare success.
Hey there, Boris. It's been a while since I maintained this code, but I'll take a guess. > 1. The visible tabs after shutdown and restart are wrong - some of the > MRU logic seems to be hard coded somewhere. I seem to recall that the tab order is stored in two places. There's an implicit order in the way PaneFolder restores its nested parts, and then the presentation folder has an opportunity to reorder the tabs. If it's an order problem, it'll be in one of those two places. I'll bet it's not an ordering problem, though. It could also be a visibility thing. Even if you get the order right, the tab folder will hide inactive tabs when you have it set to CTabFolder.setMRUVisible(true). I don't think the set of filtered tabs is ever persisted anywhere - it just occurs as a side-effect of the order in which you restore the tabs. If you remove the CTabFolder.setMRUVisible(true) call and restart Eclipse, I'd expect the set of visible tabs to change once... but on subsequent restarts, the order should be persisted okay. That's probably an acceptable limitation. What were your steps to reproduce? > 2. Sometimes you will end up in a state where the current active tab > is not showing at all. I was able to reproduce this by Ctrl-clicking > on class names several times. This bug would almost have to be within CTabFolder itself. I think that's the code that enforces visibility of the active tab. Last I checked, though, the code was the same for MRU on and off. BTW, when I first filed this bug I didn't make the change myself because Michael and Doug were against it. (One was my boss and the other was the official owner of the editor management component). Now that neither of them are on the UI team, I'll bet the change would go unopposed if you simply removed the MRU behavior. I only ever endorsed adding a preference as a compromise to the other committers who liked MRU. If nobody is fighting for it anymore, we should just do away with this behavior and save the clutter of an additional preference. However: I don't have a problem with making it a preference if this is still a hot topic with someone.
+1 ! :-)
Woohoo! Good too see this discussion is finally moving forward :)
Judging from Boris' comments, it sounds like he'd be willing to accept a community patch if someone were willing to submit a well polished one. There's a lot of people cc'd on this bug. If one of you were willing to write a patch, here's where I'd start: - Search for callers of CTabFolder.setMRUVisible. There will probably be one in Default*Presentation or somewhere else in the same package. Getting rid of that will disable the MRU behavior. - Look in CTabFolder for the tab visibility problem Boris mentioned. It will probably either be a bug in the layout code itself or a missing call to trigger a layout. - For the "remembering tabs between sessions" bug, look in the Default presentation factory (its called DefaultPartPresentation or something). Look in the constructors and the persistence methods. The bug will probably either be there or in the way CTabFolder chooses its initial window of visible tabs. - If you want to add left and right arrows for scrolling the tabs, you'll also need to go to CTabFolder. There's still a copy of the "classic look" CTabFolder that is being used for the 2.1 presentation plugin. I think it may have some code for scrolling tabs, and there may be some code in there you can salvage. I don't recall the class name, but search for classes with "Presentation" in their name and you should find the code that instantiates the old-style folder pretty quick.
Thanks Boris for your patience in this discussion. And thanks Stefan for dusting off those neurons :) I think the tweaklet approach has merit. It works for Firefox and it could work for us if we could get the awareness up and make the pattern more pervasive as a way to alter the default behaviour of Eclipse. Maybe the delivery via p2 needs to be made more apparent. Although I personally dislike MRU I never run with the tweaklet because well I'm lazy so that's what I get. Plus unfortunately people (me included) get used to the way things work even if it's suboptimal, so the change must be substantially better for one to get over the effort hump. And, some people actually like MRU. Eclipse is used in a huge number of kinds of applications by a huge number of different user types. I think it's unrealistic to believe that any single (or two) way/s of managing tabs in Eclipse will satisfy those varied requirements. I think that's been our mistake in the past, MRU included. Thus personally I'm not interested in adding a preference, I'm interested in fixing the default behaviour, and providing alternatives appropriate for a given audience. What would speak volumes is if there was a groundswell adoption of a particular tweaklet. Real adoption, wide adoption, representative, real usage, concrete feedback and refinement. Good ideas get better, bad ideas don't hurt everyone, anyone can play. That kind of progression would provide the level of assurance needed for changing the behaviour as the default. It would also indicate which alternative tweaklets were candidates as optional behaviour (either included by default in the SDK or delivered via a "top mods" p2 site).
Remy is now responsible for watching the [EditorMgmt] component area.
For a long time, I've noticed that sometimes when I close an editor tab, instead of the other tabs sliding over to "fill in the hole", a seemingly random open editor tab replaces the one I just closed. But sometimes not. Also, since the tab labels are all different sizes, sometimes what had been the next tab moves a bit to the left, sometimes it moves a bit to the right, and sometimes it does what I would have expected (moving to replace the one I just closed). Boy, this is a long issue thread. Am I about to rehash a lot of what's been said here? Probably. But here is my vote: I think at the least, Eclipse should have uniform tab behavior. Maybe all of Eclipse's other tabs ought to be made to behave like editor tabs so a user will know what to expect. Most of Eclipse's tab behavior is just like the tab behavior of a lot of other programs out there. Except for editor tabs. The worst part of Eclipse's editor tab behavior is when you close a tab. Most other programs that support tabs; Opera, Firefox, Chrome, Gnome-Terminal, Geany, Pidgin, etc.; have a uniform tab size (sometimes based on how many tabs are currently visible) and when you close a tab, the tab order is maintained. Opening and closing tabs doesn't change the order of other tabs in the list. This provides a rapid way to close the last N tabs that were opened by just holding the mouse in one place and clicking the middle button N times. In Eclipse, every time I close a tab, I have to check where the next tab has moved. I don't buy that there is a silent majority that likes this behavior. I think there is a silent majority that finds it irritating, but hasn't yet registered for a bugzilla account so that they can file a bug report. If some people like the current behavior, can it be made an option (not the default)? Here's what I think the default behavior should be, which would make Eclipse's editor tabs behave like the default tab behavior for the programs listed above: 1) opening and closing tabs should be simple insertions and deletions. E.g. when you close a tab, the remaining tabs should "fill in the hole" (nifty animations like Chrome's are optional :) ), maintaining tab order. 2) tabs should have a uniform size (possibly dependent on how many tabs are open) Bill Burdick
Has this been fixed yet? It's extremely annoying.
OMG, I just found comment 95. THANK YOU! THANK YOU! THANK YOU! I have now downloaded and installed the tweaklet that turns off the ATS feature (automatic tab scrambling). I've been siliently agonizing about this "enhancement" for 2 years. I finally stubmbled across this page http://andrei.gmxhome.de/eclipseMRUbug.html that pointed me to this bug. I've apparently been part of the "silent majority" that has hated this feature and didn't know how to turn it off, and had no idea who to complain to. OMG, why can't they just PUT IT IN THE CONFIG to let users turn this automatic tab scrambling "feature" off. I guess it's called MRU, but I think it should be called ATS -- automatic tab scrambling. After 5 minutes of following through various calls of a large project, I have been getting hopelessly lost trying to figure out where the tab I originally wanted went to. I don't understand why eclipse ever implemented ATS. Thank you to the user community whomever fixed this for me! It's just so sad that it took me over 2 years to stumble upon it.
*** Bug 340520 has been marked as a duplicate of this bug. ***
Finally ! After years of being confused I found the link http://andrei.gmxhome.de/eclipseMRUbug.html and now my tabs are left alone. Thank you Andrei! What a relief.
Eclipse 4.1 has not MRU yet so it provides what you request in this bug. I've filed bug 344029 against e4 which should at least bring the 3.x behaviour back by setting a preference.
Oh no. Now it all starts again. Couldn't we just let that thing silently die?
+1 for just letting the MRU tabs silently die in E4.
+1 I find MRU tab ordering very unproductive. I just want CTRL+Page to cycle through files I have opened the order I had them opened. No fanciness please.
+1, there should be an option to turn this off and use a traditional scheme, which keeps adding tabs to the right side (and maybe add << and >> buttons to scroll the tabs list back and forth, although the down-arrow drop down list is acceptable too)
Personally I can't even work without the MRU editor tabs visibility policy in e4 standard theme. I don't know how people are accepting to continuously jump into the ">>" list when there are many open editors (I usually work with dozen open editors... and yes, I need them!). Just working on a file, then on another and jumping back and forth is forcing me to always open the ">>" list and search for the file I need, while I could simply do a click in Eclipse 3.x because the most recent editors were at hand. This is also in contrast with the Mylyn principle of "context", which declared the success of Mylyn itself. I opened but #393002 to request an option in Window | Preferences that works independently of the chosen theme: this would make all people happy once and for all...
+1 for adding an option in Preferences to turn on MRU It's obvious from the size of this thread and also the number bug reports (393002, 388476, 389169) that many people like the MRU behavior, and having to edit your CSS file to turn it back on is not very intuitive. The only way you can even discover the CSS file solution is by Googling.
In Eclipse 4.2 the default CSS does not include MRU. If someone wants to have MRU he can change the CSS via Windows -> Preferences -> General -> Appearance to Classic. There are already themes out there which allow to set this flag directly, e.g. https://github.com/jeeeyul/eclipse-themes I suggest we discuss improvements of the CSS handling in Bug 386470 and close this one as fixed.
