Community
Participate
Working Groups
The arrows on the editor area: 1. What are they supposed to do? They seem to scroll the tabs but they do not change the active editor. Shouldn't they select the editor? 2. The arrows should be disabled or (better yet) hidden when there is no tabs hidden in the arrow's direction 3. I hope we'll get some icons in place of "<" and ">" characters. The characters look strange up there. 4. Open multiple editors at once (select ~10 Java files in Package Explorrer, R-click -> open). Note that the standard ">>" drop down painted multiple times while editors are opened having multiple ">>" on the screen 5. Does it make sense to have both arrows and ">>" dropdown at the same time? I had an impression that it was one or the other 6. There is a weird whitespace between ">>" and ">" that can get pretty large. See the screenshot attached. 7. Are they useful at all? I had a five minute mock-up development in which I tried to use them to switch between editors and they are just too slow comparing to drop-down. I think (7) needs to be discussed first. May be, instead of scrolling arrow would open drop-downs in either side showing "extended" header of the CTabFolder that can be scrolled?
Created attachment 209975 [details] screenshot
(In reply to comment #0) > The arrows on the editor area: > 1. What are they supposed to do? They seem to scroll the tabs but they do not > change the active editor. Shouldn't they select the editor? In a browser, the arrows scroll the tabs and do not change the active tab. > 2. The arrows should be disabled or (better yet) hidden when there is no tabs > hidden in the arrow's direction This makes sense to me. > 3. I hope we'll get some icons in place of "<" and ">" characters. The > characters look strange up there. They look okay to me but everyone's opinion on UI can be different. > 4. Open multiple editors at once (select ~10 Java files in Package Explorrer, > R-click -> open). Note that the standard ">>" drop down painted multiple times > while editors are opened having multiple ">>" on the screen Good observation. This doesn't seem to happen on 3.x. > 5. Does it make sense to have both arrows and ">>" dropdown at the same time? I > had an impression that it was one or the other That was the original plan but then I realized people that wanted a way to see all the tabs would not be able to unless they knew about Ctrl+E. > 6. There is a weird whitespace between ">>" and ">" that can get pretty large. > See the screenshot attached. I've seen that. > 7. Are they useful at all? I had a five minute mock-up development in which I > tried to use them to switch between editors and they are just too slow > comparing to drop-down. > > I think (7) needs to be discussed first. May be, instead of scrolling arrow > would open drop-downs in either side showing "extended" header of the > CTabFolder that can be scrolled? Not sure I fully understand your suggestion here.
Created attachment 210021 [details] multiple "editor areas" I think this kind of navigation aide has some potential, but agree with Oleg's reservations (in particular that it should be an icon that potentially could be "themed" or "styled" not just the '<' and '>' characters)... and wonder ... is it is essential for 4.2? And, if not, should it appear in M5 in its current form? Also, I think, conceptually, this should be applicable to any view that has tabs, right? Not just the "editor area"? Not to mention, as currently is, if you drag some editor pages to edge of "editor area", you end up with multiple "editor areas", but subsequent ones have no arrows. (see attachment.) I was confused at first too, that the editor selection didn't change ... but, confess a) I've learned it does work just like my Firefox browser and b) I never use them in my web browsers. :)
(In reply to comment #3) > ... is > it is essential for 4.2? And, if not, should it appear in M5 in its current > form? I'd say no. People probably do want a way to get the MRU ability back though. I'd be open to pulling this out. > Also, I think, conceptually, this should be applicable to any view that has > tabs, right? Not just the "editor area"? I suppose so. > Not to mention, as currently is, if > you drag some editor pages to edge of "editor area", you end up with multiple > "editor areas", but subsequent ones have no arrows. (see attachment.) Yes, there's some other code that also suffers from this discord.
(In reply to comment #4) > (In reply to comment #3) > > ... is > > it is essential for 4.2? And, if not, should it appear in M5 in its current > > form? > > I'd say no. People probably do want a way to get the MRU ability back though. > I'd be open to pulling this out. > Yes - I want MRU back!
(In reply to comment #4) > People probably do want a way to get the MRU ability back though. I prefer fixed placement (the current behavior in 4.2) over MRU any day.
I think it should be a config option and there's an extra bug for the MRU behavior open
(In reply to comment #6) > I prefer fixed placement (the current behavior in 4.2) over MRU any day. Same here. (In reply to comment #7) > I think it should be a config option and there's an extra bug for the MRU > behavior open Yes, it's bug 344029. Sorry, what I meant in comment 4 was "I think these arrows are less important for the fixed placement folks than it is to bring a config option back for the MRU crowd" in terms of 4.2 priorities.
Sorry, re-enabling MRU as a configuration option was my task. The plan was to set the option through CSS as there appears to be a desire to move towards CSS and away from preferences ... at least for styling related options. After this is in place I was going to look at adding a preference on the preference page that would drive the change into the system via the CSS file. Unfortunately I ran into some problems querying and tracking CSS changes on the property and then got side tracked by the URI stuff so I'm behind schedule. I'm still looking into it and can hopefully have something simple enough to contribute to this milestones rebuild.
Created attachment 210053 [details] Screenshot depicting the state in question. (In reply to comment #3) > Not to mention, as currently is, if > you drag some editor pages to edge of "editor area", you end up with multiple > "editor areas", but subsequent ones have no arrows. Based on your screenshot, you do not appear to have split your shared area. If you had split it it have an outer area drawn around the two tab folders.
Created attachment 210063 [details] Allow mru behaviour as an option This patch adds the ability to turn the MRU behavior on and off via the css theme file. Adding mru-visible: true; to the MPartStack section of the Eclipse theme files will: 1) Re-enable the Eclipse 3.x MRU behavior 2) Turn off the new tab scrolling arrows. The default value is FALSE, which gives the the tab scrolling arrows and the 4.2 browser style behavior. The following limitations exist: 1) Changing the theme in the preferences menu will cause the MRU behaviour specified in the CSS file to take effect immediately but will not change the visibility of the arrows until a Window -> New Window. This is actually consistant with our unfortunate CSS Themeing change strategy. 2) Editing the active CSS file will not cause the change to take effect until the workbench is restarted. Again, this is true for our entire theming story. If we get some +1s I can release this patch for today's 1:00pm build.
(In reply to comment #11) > Created attachment 210063 [details] > Allow mru behaviour as an option If MRU is turned on it is also turned on for view stacks. This is the behaviour in 3.x although I am not sure if it is the desired behaviour in 4.x. Thoughts?
I think it is most important in the Editor area, for View-Stacks I would not mind that much, though in 3.x RCP many people used views (together with ISaveablePart2) to act similar to Editors but not get shared across perspectives
Since it works like this in 3.x I guess we can let it go. (In reply to comment #11) > Created attachment 210063 [details] > Allow mru behaviour as an option Dean, please release this patch and close bug 344029 when the fix is in master.
Released MRU behavior patch: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e65ebe90dcf990700855749aa0eceea8dd0c5815
Created attachment 210070 [details] CSS File changes Patch for CSS file changes setting mru-visible to the default FALSE value, but providing the user indications of where to make the change to TRUE should they want 3.8 style MRU behavior. Attached as a patch since I don't have commit rights to the appropriate project. Paul will commit for me.
Shouldn't the style that mimics 3.x style use true?
(In reply to comment #17) > Shouldn't the style that mimics 3.x style use true? I would say no but that's just me. Though as someone that knows how to edit the CSS file it wouldn't really matter to me.
(In reply to comment #17) > Shouldn't the style that mimics 3.x style use true? I've set the 2 classic styles I see to true, e4_classic_win7.css and e4_classic_winxp.css and released that for the delayed 13:25 build. Is that good enough? PW
(In reply to comment #11) > Allow mru behaviour as an option Is the old "unibrow" mode available as an option through CSS? If not, perhaps it should be?
(In reply to comment #20) > Is the old "unibrow" mode available as an option through CSS? If not, perhaps > it should be? We have a CSSPropertySingleSWTHandler but I don't seem to be able to get it to work. Unibrow mode should definitely only be on for editors (instead of also being on for view stacks :)). I opened bug 369796 for this.
I'd like some more polish, bug 370438.
*** This bug has been marked as a duplicate of bug 369973 ***
