Community
Participate
Working Groups
4.2 M5. The fix for bug 344029 brings back MRU in the 'Classic' theme. I think it should not only bring back MRU but also show all editors again when clicking on ">>" (the hidden ones in bold). This was very useful to see the sequence of the editors. I'd also prefer that those things are separate UI preferences so that can still use the new themes but keep the MRU behavior + full editor list in the ">>" drop-down.
(In reply to comment #0) > The fix for bug 344029 brings back MRU in the 'Classic' theme. I think it > should not only bring back MRU but also show all editors again when clicking on > ">>" (the hidden ones in bold). This was very useful to see the sequence of the > editors. I am strongly considering just making the list be alphabetical without visibility considerations and without making anything bold. Also see bug 70982 and bug 179331. > I'd also prefer that those things are separate UI preferences so that can still > use the new themes but keep the MRU behavior + full editor list in the ">>" > drop-down. The chevron will always show all editors regardless of whether MRU is enabled or not.
(In reply to comment #1) > I am strongly considering just making the list be alphabetical without > visibility considerations and without making anything bold. One alternate school of thought would be to just have the list show what's in the tab from left to right if MRU is off. That is what happens in browsers though I am not sure if makes sense here.
(In reply to comment #2) > One alternate school of thought would be to just have the list show what's in > the tab from left to right if MRU is off. That is what happens in browsers > though I am not sure if makes sense here. That's what I want, and it makes sense because without it what's the point of fixed position rendering of tabs? Also there should be a visual clue about which tabs are visible. I understand (from bug 179331) bold font indicates 2 things in 3.x, maybe we can use bold+italics or just italics for visible tabs?
(In reply to comment #3) > Also there should be a visual clue about which tabs are visible. I understand > (from bug 179331) bold font indicates 2 things in 3.x, maybe we can use > bold+italics or just italics for visible tabs? Making fonts bold and/or italics isn't really a good option because such font rendering options do not work for all fonts. How about changing the background colour slightly for visible and invisible tabs like Firefox? Though I see they bold the current tab in their dropdown list.
I've pushed a change to show all tabs in the chevron for now to appease the masses. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=115ed57b622d6f37686f69f0f456c54720621774
(In reply to comment #4) > How about changing the background colour slightly for visible and invisible > tabs like Firefox? That would also work for me.
(In reply to comment #2) > (In reply to comment #1) > > I am strongly considering just making the list be alphabetical without > > visibility considerations and without making anything bold. -1 for that. > One alternate school of thought would be to just have the list show what's in > the tab from left to right if MRU is off. That is what happens in browsers > though I am not sure if makes sense here. That's exactly what I'd like to see! And I would even do this in MRU mode. MRU should affect how editors are opened, closed and put out of the tab list but not how the list is sown. (In reply to comment #4) > How about changing the background colour slightly for visible and invisible > tabs like Firefox? Though I see they bold the current tab in their dropdown > list. +1: make the background for hidden ones a bit more bright and the active one bold.
(In reply to comment #7) > (In reply to comment #2) > > (In reply to comment #1) > > > I am strongly considering just making the list be alphabetical without > > > visibility considerations and without making anything bold. > > -1 for that. What exactly are you -1'ing, Dani? In 3.x there were bold fonts and the visible and invisible editors were sorted in alphabetical order (separately). Didn't you want this back? I presume that's why you opened the bug. Or perhaps what you are against is having the list be alphabetical but there being no distinction between visible and invisible editors? > > One alternate school of thought would be to just have the list show what's in > > the tab from left to right if MRU is off. That is what happens in browsers > > though I am not sure if makes sense here. > > That's exactly what I'd like to see! And I would even do this in MRU mode. MRU > should affect how editors are opened, closed and put out of the tab list but > not how the list is sown. That feels too confusing for MRU users in my opinion. If MRU is on then I would think the list should be alphabetical. Tab ordering is clearly not what they are concerned about so why show them a list that matches the tab ordering? > (In reply to comment #4) > > How about changing the background colour slightly for visible and invisible > > tabs like Firefox? Though I see they bold the current tab in their dropdown > > list. > +1: make the background for hidden ones a bit more bright and the active one > bold. So I think what you mean is to make the invisible ones have a lighter background colour and the visible ones a darker background colour?
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > I am strongly considering just making the list be alphabetical without > > > > visibility considerations and without making anything bold. > > > > -1 for that. > > What exactly are you -1'ing, Dani? All in that sentence ;-) - I don't want it sorted alphabetically - I want to see the difference between visible and invisible ones > > > One alternate school of thought would be to just have the list show what's in > > > the tab from left to right if MRU is off. That is what happens in browsers > > > though I am not sure if makes sense here. > > > > That's exactly what I'd like to see! And I would even do this in MRU mode. > >MRU > > should affect how editors are opened, closed and put out of the tab list but > > not how the list is sown. > > That feels too confusing for MRU users in my opinion. I don't see how alphabetical order correlates to MRU behavior and I'd bet that most people won't know that we have two separate lists each alphabetically sorted. The 3.8 look where all active editors are bold, isn't useful. If we really want to keep two separate lists then they'd better be separated by a real separator instead of using bold style. Though my vote is to drop that also for MRU. > > (In reply to comment #4) > > > How about changing the background colour slightly for visible and invisible > > > tabs like Firefox? Though I see they bold the current tab in their dropdown > > > list. > > +1: make the background for hidden ones a bit more bright and the active one > > bold. > > So I think what you mean is to make the invisible ones have a lighter > background colour and the visible ones a darker background colour? I guess if you make the invisible ones just "more bright" (background), then you might not have to touch the visible ones.
(In reply to comment #9) > - I don't want it sorted alphabetically > - I want to see the difference between visible and invisible ones Okay, when you reopened the bug, I assumed you liked the 3.x behaviour. Now I see you are against it. > I don't see how alphabetical order correlates to MRU behavior and I'd bet that > most people won't know that we have two separate lists each alphabetically > sorted. There is no direct correlation (in my opinion) but Ed Willink has been asking for it, see bug 344029 comment 4 and bug 344029 comment 10.
(In reply to comment #10) > (In reply to comment #9) > > - I don't want it sorted alphabetically > > - I want to see the difference between visible and invisible ones > > Okay, when you reopened the bug, I assumed you liked the 3.x behaviour. Now I > see you are against it. No, I did not ask for the 1:1 behavior being restored, but just show all editors again. From comment 0: " but also show all editors again when clicking on ">>" (the hidden ones in bold). This was very useful to see the sequence of the editors. " As you can see, I already dreamed to have the sequence/order as they appear in the tab bar :-).
(In reply to comment #10) > There is no direct correlation (in my opinion) but Ed Willink has been asking > for it, see bug 344029 comment 4 and bug 344029 comment 10. I suspect there are two differently valid use cases. If there are only a few editors, or a very disciplined open/close practice, MRU is good. If there are many, I often have over a hundred editors open, in randomish debugger stepping, F3 browsing order, alphabetical is essential. Perhaps, a Windows preference for the default and/or some kind of toggle on the chevron.
(In reply to comment #12) > (In reply to comment #10) > > There is no direct correlation (in my opinion) but Ed Willink has been asking > > for it, see bug 344029 comment 4 and bug 344029 comment 10. > > I suspect there are two differently valid use cases. > > If there are only a few editors, or a very disciplined open/close practice, MRU > is good. > > If there are many, I often have over a hundred editors open, in randomish > debugger stepping, F3 browsing order, alphabetical is essential. Can you explain in more detail how alphabetical order helps if you have hundred editors? Don't you use the search field in that case anyway, or directly use Open Type/Resource?
> (In reply to comment #12) > Can you explain in more detail how alphabetical order helps if you have hundred > editors? Alphabetical order nearly always helps. Would you often want your files/classes to be listed in creation time order. > Don't you use the search field in that case anyway, Wow. I never knew there was a search. I just thought there was a missing menu title! There could be a background color differentiation to show the text field. > or directly use Open Type/Resource? Sometimes. Sometimes the files I want are the search window. Sometimes I just like to browse and that's exactly what 3.8 supports and for which I could not adjust to lack of support for on 4.2. I suggest a little a^z icon on the chevron menu. Ctrl-E makes the 4.2 platform useable for me. Unfortunately Bug 370570 is now the blocker on 4.2 usage for me.
(In reply to comment #14) > > Don't you use the search field in that case anyway, > > Wow. I never knew there was a search. I assumed you had a preference for the mouse over the keyboard as I had suggested the text filtering before (bug 344029 comment 5) and Ctrl+E twice (bug 344029 comment 5, bug 344029 comment 12) but I guess this isn't the case.
(In reply to comment #15) > bug 344029 comment 12 That should have been bug 344029 comment 11.
Looking at this bug and also at what I've implemented before in Extended VS Presentation plugin (see for example http://andrei.gmxhome.de/skins/examples.html), I'm wondering what it is all about. Why not let user decide if he wants to see alphabetical/natural sort order? Why not just be flexible? Why should it be "one fits all" question and not "you can have whatever you like"? In my plugin there are followed settings: - "active" tab is bold and has "[current]" suffix to better catch it - "dirty" editors are red - "hidden" tabs have different background - "visible" tabs *can* be shown as bold (menu option) - all tabs *can* be sorted/shown "as is" in the stack (toggle button) - visible and hidden tabs *can* be grouped (menu option) - one *can* choose to see just file name or full path (menu option) - tooltip with full path is shown on mouse over Of course all options are automatically persisted, so whichever style you prefer, UI will automatically remember it and you have no need to setup all this again and again. As you see, there is a lot of "can" choices and so far there were no problems reported. P.S. Unfortunately my plugin does not work in 4.2 anymore, but I see this is a chance for 4.x stream in the "standard" Eclipse to make things right...
*** Bug 386581 has been marked as a duplicate of this bug. ***
Please just make the ordering of the menu configurable. BTW if MRU means most recently used, it doesn't seem to work. I'm talking about the tabs. I would prefer that the visible tabs are the most recent set that I have looked at.
And it would be really nice if the editor I am looking at (but have not selected/given focus to) in the Debug perspective is the editor I look at when I switch to the Java perspective; just like 3.x!
(In reply to comment #20) > And it would be really nice if the editor I am looking at (but have not > selected/given focus to) in the Debug perspective is the editor I look at > when I switch to the Java perspective; just like 3.x! This "normally" works, but as soon as you start to re-arrange an editor, you take it out of the new generic shared area. In 3.x only the editor area was shared and it was not possible to drag an editor out of that area.
Compared with Indigo I'm finding Juno difficult due to the tab management and editor drop down. Using the Win7 theme I often have 20-40 editors open while working on java projects. The tab management does not maintain the MRU editors. And it's not possible to locate an open editor with a large list on non-alphabetically ordered files. At least for me. Please make this configurable (and I think it should be the default). If there is a workaround please post it. Thanks!
(In reply to comment #22) > > If there is a workaround please post it. Thanks! The only workaround ATM is to use CTRL+SHIFT+E which pops up the Switch to Editor dialog. PW
Paul, thank you, I had missed that. That option will allow me to stick with Juno and not go back to Indigo. The problems with MRU tabbing are still bad but this helps a lot.
*** Bug 53609 has been marked as a duplicate of this bug. ***
I miss the alphabetical list but a bigger gripe is when you close files via the drop down list they aren't removed from the list, and there is no close-all option. Both were features of Indigo.
(In reply to comment #26) > I miss the alphabetical list but a bigger gripe is when you close files via > the drop down list they aren't removed from the list That's bug 380138 PW
This got fixed some time ago (R4.2) but marking the hidden ones bold. That was fixed later with bug 385987 and bug 411503. Not using bold for the hidden ones is covered by bug 70982.
