Community
Participate
Working Groups
4.2.1 RC2 - close all editors - open a few editors A, B, C, D, ..., Z until the overflow chevron appears - directly switch back to editor A (using Ctrl+Shift+F6, Ctrl+E, Ctrl+Shift+T, ...) => editor tab for Z is not visible any more Chances are high that I soon want to switch back to the most recently used editor Z. In 3.8.1 RC2, Z is readily available (as rightmost tab); the invisible tab is B, which has not been used in a long time. This MRU behavior was useful, since it always provided direct access to tabs of the most recently used "working set". Now, Ctrl+F6 is the only way to move around in the "working set", and the tab bar becomes quite useless, since it constantly scrolls around and never shows the editors I'm working with. Please restore the MRU behavior or at least make it available as an option.
For some reason I think MRU behaviour is only available in Classic mode. Eric? PW
My understanding (not complete by far...;-) is that it's controlled by CSS. Perhaps the 'Classic' css has the setting 'true' while the others use 'false' ?
*** Bug 393002 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > My understanding (not complete by far...;-) is that it's controlled by CSS. > Perhaps the 'Classic' css has the setting 'true' while the others use > 'false' ? It's controlled by: swt-mru-visible: true; PW
Me too. I'm wasting significant time searching for the previously used editor. A thing I didn't even think about in Eclipse 3.x. Can this please be made configurable by normal Eclipse workflows, i.e., preferences, not hacking some files deeply hidden in the directory structure?
(In reply to comment #5) > Me too. > > I'm wasting significant time searching for the previously used editor. A > thing I didn't even think about in Eclipse 3.x. > > Can this please be made configurable by normal Eclipse workflows, i.e., > preferences, not hacking some files deeply hidden in the directory structure? you can get the behavior back by switching to "classic" mode in the "general/appearance" preference.
The main intention of this bug is to make MRU the default (due to its better usability). And we all know that "Classic" will disappear after a few releases, so even if it doesn't become the default, it should at least stay available.
I agree with Markus.
Given the fierce debate *against* the MRU behavior in the past (bug 68684 with 59 votes), I wouldn't insist on having it *by default*. At this point it seems impossible to achieve consensus about MRU in the community, so top priority should be to make the choice easily available. Switching to classic because of this behavior is not an option as it would exclude us from other discussions about usibility problems of the new theme (and in the end we'd be blamed for not raising our voice).
(In reply to comment #9) > Given the fierce debate *against* the MRU behavior in the past (bug 68684 > with 59 votes), I wouldn't insist on having it *by default*. I agree that having it configurable would be enough. However, please consider that bug 68684 is not an indication on how the MRU was really appreciated or not. I think that there are thousands developers using some distribution of Eclipse worldwide that were happy with the MRU behaviour. I was one of them and I have known about bug 68684 only since I found this precious feature missing in Eclipse 4.2. Obviously, no one of the users enjoying the MRU behaviour would have certainly searched about bug 68684 and voted against it! This said, I think that if the decision were to restore the MRU behaviour as the default one, it should be seen as a fix of a regression or as a "backward compatible" choice. Moreover, I'm convinced that the MRU feature was a plus for Eclipse compared to other text editors. Eclipse is a platform and an IDE, not simply a feature rich text editor and leaving an advanced feature like this off by default (instead of letting the user disable it if he doesn't want it) doesn't make too much sense for me. It would be like providing a word processor with automatic correction disabled by default...
I didn't wade through the whole bug 68684, but I guess many of the users who didn't like the MRU behavior actually wanted multi-row tabs, not a sliding tab window. Moreover, typical interaction patterns in an IDE are different from common usage in web browsers. E.g., in browsers, you rarely click a link and then end up in an already-opened tab.
The MRU won't be the default in the Juno theme, just classic. CSS is the mechanism to control the appearance of eclipse going forward. That *is* the workflow that everybody will work with. That's where we'll be expending our effort. We will not modify the appearance with CSS and then resurface most of it with preferences (allowing preferences to change values in the CSS), although we hope to surface preferences the other way so they can be set from the CSS. PW
Wow, that's gross! You remove useful functionality and replace it with CSS hack? How should a user ever find out about this functionality and where should he apply these hacks so that they also survive a reinstall of Eclipse? Exporting/importing of preferences did the job in the past. The Eclipse IDE is not a web app. It was based on engineering principles and was meant to be user friendly. Why should this change now? And why did you not answer on the actual topic (*why* MRU won't be the default)?
(In reply to comment #13) > Wow, that's gross! You remove useful functionality and replace it with CSS > hack? CSS may be a hack (although I wouldn't say that myself :-) but that's what was decided and that's what we're going forward with. > How should a user ever find out about this functionality and where should he > apply these hacks so that they also survive a reinstall of Eclipse? > Exporting/importing of preferences did the job in the past. Right now they survive eclipse installs because they're kept in home. But adding an export/import path is good. > > The Eclipse IDE is not a web app. It was based on engineering principles and > was meant to be user friendly. Why should this change now? Because that was the whole point of the last 4 years of working on Eclipse4. The discussions are all in e4-dev and on various bugs. > And why did you not answer on the actual topic (*why* MRU won't be the > default)? Sorry, the why: because we made the change based on the feedback in newsgroups, lists, and bugs like bug 68684 PW
Still can't understand this! First of all, isn't CSS about "Cascading *Style* Sheets"? How can the logic that handles the policy of closing editors be considered "style"?? And then, other questions: 1) why am I forced to use a "Classic" theme (the word classic sounds to me as "obsolete", "deprecated"...) to use an advanced feature like this? 2) why am I supposed to edit/change the platform "theme" to enable/disable a feature? 3) how can I change the MRU policy in my Eclipse IDE? I still can't find any way of doing this by Preferences. As Markus said, this is not a webapp, it's a standalone application for which I'm supposed to be able to change preferences using Window | Preferences. I never saw any application for which I have to hack a CSS file in order to change preferences and/or to enable features... (well, many *ancient* Linux applications needed something like this, is this the real way Eclipse want to go for the *future*?). Not mentioning the missing import/export capabilities that Markus already cited... 4) (last, but not least) I really can't understand how a developer which is using Eclipse seriously can work with the current way open editors are handled...
(In reply to comment #15) > Still can't understand this! > > First of all, isn't CSS about "Cascading *Style* Sheets"? How can the logic > that handles the policy of closing editors be considered "style"?? > Because it's not closing editors. It's choosing how they're displayed. PW
Paul, seriously, do you use Eclipse for your daily work? I think so. Well, how do you handle this typical use case: - consider a good amount of open editors (10 is enough... I usually have at least 20) - choose one of the open Java files, then hit F3 on a method to go to its declaration then jump deeply with F3 on another method and so on for 3-4 levels of method calls - then, you want to go back to the first Java file you started from - previously, that file was just there! Now, you have to click to ">>", search for the file (previously, the bold font was marking the invisible ones, now the font is the same for every file!!!) and click it - ok, now you have to go back to the last-but-one file... again, you have to click on ">>", search for the file, etc., unless you are luck enough to have it on the list of visible open editors (because the order in which you have opened it is the same in which you are jumping from one file to the other) Otherwise you need to franticly click the "<-" and "->" buttons in the hope that they work as you need (honestly, they often drive me crazy!). It's a nightmare for me!
(In reply to comment #15) Mauro, the CSS story is implemented but not full-featured yet. Things like this will be found and dealt with in this and future releases. With that in mind: > And then, other questions: > 1) why am I forced to use a "Classic" theme (the word classic sounds to me > as "obsolete", "deprecated"...) to use an advanced feature like this? You are not forced. You can also change your current theme. The idea is that we will see advanced theme managers that can be customized from the preferences. Please download the Chrome Theme from marketplace and take a look at how can become. http://marketplace.eclipse.org/content/eclipse-4-chrome-theme This theme enables you to enable/disable MRU from the preferences. > 3) how can I change the MRU policy in my Eclipse IDE? I still can't find any > way of doing this by Preferences. As Markus said, this is not a webapp, it's AFAIK, you can add CSS attributes through the preferences by using the above mentioned chrome theme or to change the CSS from the preferences. Go to Preferences/General/Appearance
(In reply to comment #18) > Mauro, the CSS story is implemented but not full-featured yet. Things like > this will be found and dealt with in this and future releases. This bug report was about dealing with one of these aspects and it has been closed as "WONTFIX"... > You are not forced. You can also change your current theme. The idea is that > we will see advanced theme managers that can be customized from the > preferences. > > Please download the Chrome Theme from marketplace and take a look at how can > become. Oh, yes, but if this Chrome theme lets you enable/disable the MRU from the preferences, why the *default* one doesn't? I'm not a big fan of themes as soon as they become the excuse to say "try another theme" when you highlight a missing important "feature" of the default one. I shouldn't need another theme if the default one fits well, at least if it's just for taste. Also, I don't have time to browse huge archives of user themes, where most of them will certainly be simply unusable and I have almost no criterion about choosing among one or the other. This has happened for me since the "Windows 95 Plus Pack" times, going through Firefox and all the other browsers with the recent tendency to spend effort on things like this, instead of improving on existing *actual* features. Sorry for being sharp, this is just my point of view. > AFAIK, you can add CSS attributes through the preferences by using the above > mentioned chrome theme or to change the CSS from the preferences. > > Go to Preferences/General/Appearance I can't find a way to change CSS attributes from there. I'm using Eclipse 4.2.1 (M20121107-1200). I also tried to type "CSS" in the filter text field, but I only find preferences for the WTP CSS Editor plugin.
(In reply to comment #16) > Because it's not closing editors. It's choosing how they're displayed. Ok, sorry, I used the wrong wording. But I still think that the algorithm used to choose the order in which they are displayed over time is not much about "styling" (or "view", if you prefer), but rather about "control"/feedback based on user interaction and usage workflow. I think it's much more than simply visual styling.
(In reply to comment #17) > search for the file (previously, the bold font was marking the invisible > ones, now the font is the same for every file!!!) and click it File bug 394104 for this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=394104
(In reply to comment #17) > Paul, seriously, do you use Eclipse for your daily work? I think so. Yes, I'm the Platform UI component lead. > Well, > how do you handle this typical use case: Honestly? I use CTRL+F6/CTRL+SHIFT+F6 most of the time (which cycles through an MRU list) or CTRL+SHIFT+E (which opens a dialog with editors sorted by name, and start typing the name) or CTRL+3 (quick assist you can type open editor names) or as a last resort CTRL+E (the dropdown, but you can start typing the editor file name). I usually don't get past CTRL+F6 or CTRL+SHIFT+E PW
(In reply to comment #22) > Honestly? I use CTRL+F6/CTRL+SHIFT+F6 most of the time (which cycles > through an MRU list) or CTRL+SHIFT+E (which opens a dialog with editors CTRL+F6/CTRL+SHIFT+F6 are fine if you need to go one step forward or one step backward. But if you need to jump they are not. > sorted by name, and start typing the name) or CTRL+3 (quick assist you can > type open editor names) or as a last resort CTRL+E (the dropdown, but you > can start typing the editor file name). In all of these cases you need to TYPE the name of what you want. This is the same as using Ctrl+Shift+T or Ctrl+Shift+R to open a type or a generic resource. This is not an alternative, unless you consider a 2/3-keys keyboard shortcut+n typed keys as fast as just clicking on an editor title tab (like it was possible before)... Then, multiply the number of keys you need to press for the number of times you need to switch from an editor to the other.........
(In reply to comment #23) > (In reply to comment #22) > > Honestly? I use CTRL+F6/CTRL+SHIFT+F6 most of the time (which cycles > > through an MRU list) or CTRL+SHIFT+E (which opens a dialog with editors > > CTRL+F6/CTRL+SHIFT+F6 are fine if you need to go one step forward or one > step backward. But if you need to jump they are not. This works for as many as you need to go, but in your example about 3 or 4 is easy to do. > In all of these cases you need to TYPE the name of what you want. This is > the same as using Ctrl+Shift+T or Ctrl+Shift+R to open a type or a generic > resource. This is not an alternative, unless you consider a 2/3-keys > keyboard shortcut+n typed keys as fast as just clicking on an editor title > tab (like it was possible before) And in theory taking your hand of the keyboard to move to the mouse is slower than typing a couple of keys (and developers type fast). But this bug is not about which is faster. You just asked how I would deal with your scenario. PW
Paul: We care about the user experience, and you should as well. The fact that you cannot answer the simple questions raised here is proof enough that the design is fundamentally flawed. And just because you personally don't use editor tabs doesn't mean you should neglect good UX arguments and declare bad paradigms the way to go forward (that applies for MRU as well as for using CSS for user preferences). Good developers spend more time reading code than writing code. When you're in browsing mode, then clicking a tab is faster than remembering MRU order or pressing Ctrl+F6, reading the list, and choosing the right editor.
(In reply to comment #24) > And in theory taking your hand of the keyboard to move to the mouse is > slower than typing a couple of keys (and developers type fast). If I'm *browsing* the code I am not *writing* the code. So I have one hand on the keyboard and one on the mouse. If I have to type I have to leave the mouse to use both hands to type. Then, I have to move my hand back on the mouse because most of the times I have to scroll up/down and/or to move between class members using the outline view. Mouse is also very handy to see Javadoc or error hovers without having to press a lot of keys just to move the cursor to reach a method call/declaration and press F2 to see the hover. If I use Ctrl+F6 and/or Ctrl+Shift+F6 I also have to use two hands because CTRL and F6 are really distant from each other (I do not have such a big hands...). And even if I may try to press CTRL with the left thumb and F6 with the left middle finger, having to use the SHIFT modifier to change between backward and forward (rather than having two different close function keys, one on the left and one on the right) takes up my brain and forces me to certainly use two hands. > But this bug is not about which is faster. You just asked how I would deal > with your scenario. I do not agree. The problem of the missing MRU feature is all about usability and ergonomics. And we are certainly talking about this! It may sound as a dumb disquisition, but I'm also a software designer and I know how valuable ergonomics can be.
Regarding the scenario, just look at comment 0: as a mouse addict one/I can simply click on 'Z' - this is now gone and productivity is lost. There was never a consensus that MRU was bad. I can imagine that some people are overwhelmed by it but there are also a lot who love it and for those users there must be a preference to enable this in 4.x, especially since it is the 3.x behavior. Forcing Eclipse users to edit some file to get their expected behavior back is really not a reasonable approach.
Sorry Dani, but they don't edit a file. They edit it in the Appearance Preference page, CSS editor. It wasn't ready for inclusion with Juno, that's why it's a different install, but it is available both from the e4 site and in the general eclipse marketplace. I understand that some people don't want to edit CSS, but that's the mechanism going forward. PW
(In reply to comment #28) > Sorry Dani, but they don't edit a file. They edit it in the Appearance > Preference page, CSS editor. It wasn't ready for inclusion with Juno, > that's why it's a different install, but it is available both from the e4 > site and in the general eclipse marketplace. > > I understand that some people don't want to edit CSS, For good reasons. Like one (hopefully) prefers to use the Java editor over vi. > but that's the mechanism going forward. That's acceptable to style products or very exotic preferences (like Firefox offers to do via about:config), but in the year of 2012 it is not a solution that I want to throw at normal users to set important preferences.
(In reply to comment #29) > > For good reasons. Like one (hopefully) prefers to use the Java editor over > vi. CSS == to painful to work with is another conversation entirely, and one that won't happen in this bug. We're still not surfacing preferences for appearance options that are controlled by the CSS. PW
This bug is about usability in a matter where a significant (large, huge, overwhelming, I don't know) subset of the community is dissatisfied with the current default. In addition to striving for excellent defaults, usibility is about discoverability, i.e., if s.t. doesn't look / work the way I expect/want/need it, it should be extremely easy to find out what I need to do to change it. I wouldn't entirely rule out editing CSS, but in its current support its light years away from good discoverability etc. For the matter at hand we can't wait for the huge leap forward that's needed to make CSS editing a feasable approach for the masses. Interestingly, although I'm a very long term Eclipse user, Ctrl-F6 had until now escaped my attention (luckily it's not Ctrl-Alt-F6, which would hyperport me to a login prompt on a fresh new text console :) ). Was I just lazy? No, Ctrl-F6 is not well discoverable, because it has no representation in the UI. Since this discussion seems fiercely dead-locked and since discoverability is largely neglected, I suggest opening up the discussion, to admit a few fundamental, new, crazy questions, like: - do we need editor tabs at all? Isn't that wasted screen real estate? - tabs work good for a small number of items with infrequent change, obviously, for many devs this doesn't apply for editors. - perhaps more different buttons a la ">>" would be of more help? - why is MRU/not MRU considered a preference? - couldn't it be seen en par with "sort alphabetically" in the outline? (maybe sort alphabetically should be controlled by CSS, too? ;-P ) -> add a button "mru" to the tab bar and all will be happy! - since I'm a fan of bread crumbs, wouldn't it be cool if bread crumbs could be toggled between containment and MRU? (say by pressing Ctrl while hovering) - other? We need to get out of our respective trenches, please. Nobody should ever need to go to bugzilla or a forum to find how he/she should get editor switching the way that best fits him/her. It should really be plainly obvious!
(In reply to comment #30) > We're still not surfacing preferences for appearance options that are > controlled by the CSS. > > PW This *might* be the ultimate goal, but until we have a user-friendly way to edit the CSS (e.g. with content assist, description of the options, etc.) inside the SDK, we need to be open to other approaches like surfacing some of the important things as real preference, since I do not believe that we have time to provide such an editor for 4.3.
> Ctrl-F6 is not well discoverable, because it has no representation in the UI. It's in the Window > Navigation menu, but I agree it's hard to discover and I agree with Mauro that Ctrl+F6 is not the greatest shortcut. I always set it to Alt+` (the key on top of the Tab key). And I never look at the popup, since that would need a context switch, which takes too long. When I'm not sure about the MRU history, then I just look at the editor tabs and directly jump to the sought editor -- but this is broken now.
(In reply to comment #30) > (In reply to comment #29) > > > > For good reasons. Like one (hopefully) prefers to use the Java editor over > > vi. > > CSS == to painful to work with is another conversation entirely, and one > that won't happen in this bug. > > We're still not surfacing preferences for appearance options that are > controlled by the CSS. Paul, this is obviously not an appearance option. Can you tell whether it is set or not by looking at the Eclipse window? No. That's what 'appearance' means. This is a behavioural change, and a very annoying one. I can't understand the logic of closing a tab and moving focus to some other tab that I've not looked at in hours and, more often than not, wasn't even aware was open. As for the keyboard vs mouse discussion, that's got nothing to do with it. I close tabs with the keyboard all the time. However I do it, it's still confusing to end up somewhere random.
I'm in agreement with Dani that something that's causing this much angst with a lot of users needs *something* to allow the toggling of MRU mode... Would it be possible to produce <x>-MRU versions of the CSS files ? For example new 'Win7Blue-MRU.css' that simply includes 'Win7Blue.css' and overrides only the 'mru'...
*** Bug 414684 has been marked as a duplicate of this bug. ***
Not that my 2 cents means anything, but this change has decreased my productivity by something like 10% - 15%. It is inconceivable to me that someone could make this magnitude of a change without providing an option to revert to the old behavior. I have tried the "CSS" hack and the editor plugin is showing errors in the standard CSS and does not allow me to apply the change. I use the tab bar as a history and the MRU functionality was the perfect UI paradigm for that. While it might not make sense for "usability" experts, or whoever the person is who made the suggestion to change the behavior, the new behavior is utterly useless *to me*. I think that implementing this change without a fallback option speaks to a lack of leadership at the Eclipse Foundation. No product manager or customer advocate at any real company would allow this change without a reasonable option to go back to the prior behavior. While Eclipse should be free to provide any default behavior it wants, including ordering the tabs by when they were first opened, it simply cannot pull the rug out from under it user base like this providing no reasonable opt out. For each negative comment you have here I can guarantee there are 100 people who hate the new behavior and have not spent the time to search for this bug, signup for an account, and comment on it. Please remember that there is a vast community of people who literally rely on Eclipse for their livelihood. There are startups who will fail if they lose 10% - 15% of their developer throughput. I realize that I am being very dramatic here, but you have to realize the weight of the decisions being made. Opening up a bug for comment is not sufficient, developers cannot be expected to troll though the Eclipse bug database and find bugs that may potentially affect them 2 years out and comment / vote for them. That is not a valid way to make a decision that is so critical. Please fix this bug. Please fix the process that allowed this to happen in the first place.
Ideally this bug will get fixed in a way that allows easy propagation of the setting to new workspaces. We use plugin_customization.ini files to deploy widespread configuration changes and the Workspace Mechanic for customizations at the team/individual scope.
I received complaints about missing MRU behavior from many of our users, who quoted it as a reason for not using 4.x. Our users are not used to vote in Bugzilla, but I can ask them to if that it what it takes to persuade Paul.
Many modern applications/operating-systems/apps try to help the user working on most recently used objects to be fast and avoid useless searching. So why is "eclipse" so strict to not present the last used elements by default?
I think that MRU should be the default. I use the editor tabs and was surprised when I finally upgraded to e4 to find that MRU was missing, and it's been painful ever since. I think there are a lot of users in this category (I have heard several people at my company say they find e4 unusable and won't consider upgrading).
If its impossible to agree upon editor tab behavior in years, there must be s.t. utterly broken with our understanding of this feature. At this stage those tabs just waste screen space in a way that's useless for many users. So why not simply remove those tabs entirely, and invent a new mechanism for editor selection. We could, e.g., add a few drop downs: - most recently used editors - most recently viewed - most recently modified - dirty editors - alphabetic list - editors by type - e4 ordered list - ... I don't have fixed ideas about the details of such drop downs, might be an entirely new kind of widget? Should of course support some touch gestures :)
(In reply to Stephan Herrmann from comment #42) > If its impossible to agree upon editor tab behavior in years, there must be > s.t. utterly broken with our understanding of this feature. > At this stage those tabs just waste screen space in a way that's useless for > many users. I agree with this. What is the reason to show the open editor tabs if there is no MRU. You have brought up a good point here. > So why not simply remove those tabs entirely, and invent a new mechanism for > .. > entirely new kind of widget? Should of course support some touch gestures :) I like the idea of a new paradigm for this feature.
We're in the process of doing exactly what Stephan suggests as part of Luna. We intend to introduce a policy mechanism through which various aspects of the workbench's decision making can be customized. The initial use case for these policy objects has always been to allow a 'hook' that can tell the WB where to place an 'about to be opened' element, be it editor or view. This will allow all sorts of interesting experiments... As to the other comments regarding how tough this issue is to solve; please consider that editor 'management' has *always* been a divisive issue. The problem seems to be that there are some number of fairly equally accepted but different 'correct' approaches, meaning that regardless of which one we choose we will only satisfy some subset of the community. Basically if we were to just change to make MRU the default then we'd get a different defect saying 'how could you do this to me'. BTW, I'd highly recommend the Chrome theme available from the Eclipse Marketplace. It not only has some excellent predefined themes but has an *excellent* editor, including an MRU checkbox.
*** Bug 397942 has been marked as a duplicate of this bug. ***
*** Bug 389169 has been marked as a duplicate of this bug. ***
*** Bug 393979 has been marked as a duplicate of this bug. ***
*** Bug 395908 has been marked as a duplicate of this bug. ***
"Upgraded" from Myeclipse to eclipse standard a couple of weeks ago. Since then, I am fighting with this annoying new tab order. I always thought, that I can once find a preference for switching back to the old behavior, until I found this bug report now. I can simply not believe, that there is no preference setting for this important kind of setting. Simply unbelievable.
You may use "* Classic"-Theme (e.g. "Windows 7 Classic") until this bug is fixed.
I got some pretty passionate responses on twitter when I promised to fix this. It's clear the default behaviour is a very poor user experience and needs to be addressed. Not sure MRU ordering is the correct answer but I'll work on something. At the very least, the previous editor should never be in the overflow.
(In reply to Doug Schaefer from comment #51) > I got some pretty passionate responses on twitter when I promised to fix > this. It's clear the default behaviour is a very poor user experience and > needs to be addressed. Not sure MRU ordering is the correct I have no personal preference here but want to point out that MRU seems to split the people opinion, some hate it, some love it. If we think about changing the current default, I suggest a user voting with predefined acceptance criteria (min number of votes + required percentage).
I'm sorry, I know no one who likes the current behaviour. At the very least, it's easy to reason that it's a poor user experience. When I switch away from an editor and it no longer appears in the visible tabs, how is that ever a good thing? Especially for new users who may not think to look in the overflow. We need to put the good of the many ahead of personal preference here.
(In reply to Doug Schaefer from comment #53) > I'm sorry, I know no one who likes the current behaviour. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=68684 > We need to put the good of the many ahead of personal preference here. Hence the suggestion to have a voting.
(In reply to Doug Schaefer from comment #53) > I'm sorry, I know no one who likes the current behaviour. Now you know *me*, to start counting here, but this is not an argument. > We need to put the good of the many ahead of personal preference here. So now you basically put *your* personal preference over *mine* - I don't think this is an argument either. Doug, if you are going to fix this bug (thanks!), please check the very valuable points made here already by others: # To choose the good default value, consider to use public poll # Whatever default value is chosen: users should be able to change the default value via standard Eclipse preferences page without hacking on any CSS code. The bug 68684 was so awful and caused lot of pain to many people because the lack of both points above.
(In reply to Andrey Loskutov from comment #55) > # Whatever default value is chosen: users should be able to change the > default value via standard Eclipse preferences page without hacking on any > CSS code. +10 BTW, did anything along the lines of comment 44 materialize?
I am just one person with this preference. You can go through the comments here and do an informal count. Plus the 16 votes on this bug. Plus the 5 people who responded to my tweet. Plus I'll blog about this and get everyone who saw it to come here and express their thoughts. And be careful, I haven't suggested a solution yet. As I mentioned, MRU might not be the right answer. And I agree, reordering the tabs is bad. I'm certainly not looking at a simple solution here, but to do the right thing in most cases. Make as many users happy as I can. And, yeah, some may be upset, but hopefully they're the minority. My objective is to make sure that the tabs the user is most likely to want to click on are visible. Determining that algorithm is going to be an interesting exercise. My initial gut feel is that it has something to do with time, both time since I last looked at an editor and time I've spent in an editor. I may be working on two or three files at the same time and I don't want a quick F3 to look something up to become more important than the fileset I'm working on. I also don't want the last F3 to go away since I may want to refer back to it again quickly. And I would replace editors that don't meet the criteria with editors that do, not order them in the edit area that way. Speaking of order, something also needs to be done with the order in the overflow. It definitely appears random. And I'm not sure it has the same requirements as the tabs. The tabs are for quickly getting at an editor. The overflow is for finding my editor once it's there. Alphabetic might be a better ordering there. We'll see where this goes. First I need to dig into the code and find out how these things are determined so I can play with changes. BTW, we can have a vote, but the people I'm trying to reach and make happy with Eclipse, i.e. new and casual users, i.e. the vast majority, aren't likely to vote. So I take it with a grain of salt anyway.
Oh, and a quick word on preferences. Yes, we should make the algorithm a preference. But the default should be what gives new and casual users the best experience. You don't want to give them a bad experience, and then give them an even worse one by forcing them into the preference pages.
> BTW, we can have a vote, but the people I'm trying to reach and make happy > with Eclipse, i.e. new and casual users, i.e. the vast majority, aren't > likely to vote. I doubt if the new and casual user is the vast majority of users. > So I take it with a grain of salt anyway. lol! Seriously?
I think Doug is definitely headed in the right direction. I'll add my 2 cents here based on what I have observed. 1. After reading many of the original comments on bug 68684 I am tempted to reopen it and mark this as a duplicate. I realize that sounds odd since the two seem to be opposed, but the general sentiment from both seems to be "What has Eclipse done with my editor?". In both cases, the default behavior was changed with no simple way to switch back to the previous behavior. No, editing CSS does not count as a simple way to change my preference for the behavior. 2. I have seen two alternatives proposed: using hotkeys and auto-closing editors. Ironically both are based on MRU ordering. 3. On both bug 68684 and this one, there are many suggestions for using an alternative UI such as scrolling tabs. This seems to be useful for those that don't like MRU and want to preserve some rigid "order" of their tabs, but doesn't help those that want MRU and in fact makes the problem more difficult because then it really would have to change tab order. 4. Finally, I would like to propose a solution to assist new users (including those new to a version where a change is introduced). The first time the overflow menu is triggered, display a popup to show the user what is happening and allow them to configure the settings that they prefer. See the very crudely drawn attachment. Naturally, this necessitates that all such settings are available to be changed in one common location which is accessible to the user (i.e., not a CSS file somewhere).
Created attachment 241440 [details] Mockup for proposed "first-time use" prompt
It sounds like from this discussion that there are two seemingly conflicting requirements: - Desire to have most recently used (MRU) tabs visible - Desire to be able to manually reorder tabs, e.g. to put foo.h to the left of foo.c Is it possible that these requirements don't really conflict but can both be satisfied? That is, when the user reorders tabs, they are placing constraints on the tab list but not saying they want to define the exact order of all tabs. For example, the foo.h/foo.c case. If the user moves foo.h from the right of foo.c to the first spot to the left of foo.c, they are saying, "Whenever the foo.h and foo.c tabs are visible, foo.h should be left of foo.c". But if the user hasn't used the foo.h tab in a long time and gets swapped out for a most recently used tab, then that is ok. I don't know the exact algorithm, but I hope I've made the idea clear.
The more I read here, the more I'm convinced: Tabs cannot provide a solution. No matter how smart the ordering. Tabs may be good for projects of 8 files or less. The approach simply doesn't scale. Well, the few extremely tidy among us may succeed to always close the editors that are not relevant anymore, to keep the number of tabs in a manageable range, but I wouldn't expect more than 1% of us to fall into this category :) *Forgetting* broken solutions is said to be the hardest part in innovating, right? We probably need (much) more beer to really get some creativity unleashed :) Let's use our imagination what else we could do with that screen real estate, once it's no longer wasted for the tabs of those files we don't want to see. I see two (non-exclusive) options: Short term: a clearly visible toggle button to switch modes Long term: invent one or more new widgets.
(In reply to Stephan Herrmann from comment #63) > Long term: invent one or more new widgets. Example (with definitely insufficient beer for s.t. ground breaking): Click on the title bar of the editor (remember: no tabs) opens a pane the full size of the editor. On this pane you see all "open" editors arranged in 2D according to two criteria, e.g.: - top-to-bottom: most recently used to not used recently - left-to-right: alphabetically Other criteria that could be useful: - order of opening the editors - number of keystrokes / actions (including pure navigation) performed in an editor - this information could be gradually aging over time Other means to provide information: - gradually fade out entries not used in a long time - recent items larger, older ones tiny - use previous navigation paths to connect related files Mh, some of this my just be reinventing task focused views ... anyone from Tasktop reading this? :)
(In reply to Wim Jongman from comment #59) > > BTW, we can have a vote, but the people I'm trying to reach and make happy > > with Eclipse, i.e. new and casual users, i.e. the vast majority, aren't > > likely to vote. > > I doubt if the new and casual user is the vast majority of users. Sorry, I've been working with user experience designers. If the majority of users aren't new and casual, we've failed in growing our user base.
(In reply to Doug Schaefer from comment #65) > (In reply to Wim Jongman from comment #59) > > > BTW, we can have a vote, but the people I'm trying to reach and make happy > > > with Eclipse, i.e. new and casual users, i.e. the vast majority, aren't > > > likely to vote. > > > > I doubt if the new and casual user is the vast majority of users. > > Sorry, I've been working with user experience designers. If the majority of > users aren't new and casual, we've failed in growing our user base. I think the point here is that a usability study would be much more meaningful than a vote. Hopefully many of those existing users with strong opinions would participate.
(In reply to Stephan Herrmann from comment #63) > The more I read here, the more I'm convinced: > > Tabs cannot provide a solution. I'll respectfully disagree with that, which is why I want to work on it. Tabs are for quick navigation if set up right. I've used IDEs that don't have that, like XCode, and it's one of the first things I miss, especially with larger projects. Also, I'm still not suggesting MRU ordering. I agree with everyone who's saying that it's bad. I think we can put together a smart solution that will meet both requirements.
(In reply to Cole Markham from comment #66) > I think the point here is that a usability study would be much more > meaningful than a vote. Hopefully many of those existing users with strong > opinions would participate. I definitely agree with that. My biggest problem with a vote is that it's self selecting. You want to reach out to users who represent the group you need to satisfy the most. For those that work directly with customers, please ask them what they think and feed it to this bug. The more we hear from typical users, the more we'll know what we should be working on. Mind you, we've heard from a lot of users already (see Sergey's Comment #19 for example).
So after digging into things a bit into the deep and dirty of CTabFolder, I'm starting to think this is an actual bug. For the editors, it is actually set to MRU, but that just means that the most recently used editors are kept visible while being kept in the order that they are created. However, I think there can be times when the selected editor ends up kicking out a high priority tab. Still needs more debugging to see if that's true. Something has to explain why the priorities seem to be ignored at times. At any rate, it's good to see that the design intent as currently implemented is actually pretty much aligned to what I was hoping for and should make most people happy.
Yes, the MRU implementation works great in the Classic theme and just needs to be made available again. (In reply to Doug Schaefer from comment #57) > My initial gut feel is that it has something to do with time, both time since > I last looked at an editor and time I've spent in an editor. MRU implements only the former. If you try to implement a different strategy (in a separate bug, please), then be careful and don't break the MRU ordering in Ctrl+F6 (Window > Navigation > Next Editor). That command is modeled after similar commands on the OS level (Alt+Tab / Command+Tab / Command+`) and its behavior needs to stay in sync with how things work everywhere else. Same for the "Close" command (next editor is the most recently used editor).
(In reply to Markus Keller from comment #70) > Yes, the MRU implementation works great in the Classic theme and just needs > to be made available again. > In my environment, mru was turned on. And, no it has the issue of high priority editors not being shown. > (In reply to Doug Schaefer from comment #57) > > My initial gut feel is that it has something to do with time, both time since > > I last looked at an editor and time I've spent in an editor. > > MRU implements only the former. > > If you try to implement a different strategy (in a separate bug, please), > then be careful and don't break the MRU ordering in Ctrl+F6 (Window > > Navigation > Next Editor). That command is modeled after similar commands on > the OS level (Alt+Tab / Command+Tab / Command+`) and its behavior needs to > stay in sync with how things work everywhere else. Same for the "Close" > command (next editor is the most recently used editor). Yeah, as I dig, I don't think I can really have a different order in the chevron menu than the index order of the tabs. We could play with that index order but I assume all these features use that (or do they...). First I want to fix the bug I'm seeing in CTabFolder with high priority editors dropping which, interesting enough, is the bug you first raised. All this other stuff in between... :)
Ah, wait, correction, MRU is false. I must have been looking at a different tab folder when I saw it true. I'll need to take a step back and understand why MRU was so bad. I have to agree with the sentiment that not showing the most likely tabs to be selected next is just a bad user experience.
It's been a pretty good debate in both bugs. Heated at times, especially from a few individuals. And clearly the requirements conflict. We can only show so many tabs in the folder due to screen size. How do we decide which ones to show. Does strict ordering really trump the ability to have most recently used editors readily available? Clearly picking either one makes one of group of people angry. So there's no winning, except I guess for the winner. You have to hope that's the majority of users. I don't think so. The real question is which group do we want to make happier. Definitely at topic for a blog on the Planet.
(In reply to Doug Schaefer from comment #73) > It's been a pretty good debate in both bugs. Heated at times, especially > from a few individuals. > > And clearly the requirements conflict. We can only show so many tabs in the > folder due to screen size. How do we decide which ones to show. Does strict > ordering really trump the ability to have most recently used editors readily > available? Clearly picking either one makes one of group of people angry. So > there's no winning, except I guess for the winner. You have to hope that's > the majority of users. I don't think so. The real question is which group do > we want to make happier. Why not make both groups happy by making it a preference?
> We probably need (much) more beer to really get some creativity unleashed :) > > Let's use our imagination what else we could do with that screen real > estate, once it's no longer wasted for the tabs of those files we don't want > to see. > > I see two (non-exclusive) options: > > Short term: a clearly visible toggle button to switch modes Absolutely needed! > Long term: invent one or more new widgets. Once in 3.x I've played with the "opened editors" view but the lack of public API around presentation parts etc stopped me. If we would get API controlling the editor tab area and such we could easily write a view which can: - editor reoredering - editor grouping (file type or project or day of week last used) - editor hierarchies (like tree tabs extension in firefox) - editor previews in tooltips - editor highlighting - editor filtering - editor searching Etc pp. This view could provide extension points for all that. People could link it with Mylin, put it outsife of main window, pin or minimize or duplicate or place at bottom of the editor,,etc.... This would be just cool. And of course it would provide customizable and extendible editor ordering strategies.
(In reply to Sergey Prigogin from comment #74) > (In reply to Doug Schaefer from comment #73) > > It's been a pretty good debate in both bugs. Heated at times, especially > > from a few individuals. > > > > And clearly the requirements conflict [...] > > The real question is which group do > > we want to make happier. > > Why not make both groups happy by making it a preference? IMHO this is *must have* requirement fot the proper fix for this bug.
(In reply to Andrey Loskutov from comment #76) > (In reply to Sergey Prigogin from comment #74) > > (In reply to Doug Schaefer from comment #73) > > > It's been a pretty good debate in both bugs. Heated at times, especially > > > from a few individuals. > > > > > > And clearly the requirements conflict [...] > > > The real question is which group do > > > we want to make happier. > > > > Why not make both groups happy by making it a preference? > > IMHO this is *must have* requirement fot the proper fix for this bug. Agreed. Maybe that's where I'll focus my time. I remember looking for such a preference and being disappointed it wasn't there. I'll at least need it to test out how well MRU works :).
(possibly) helpful notes: The editor preference page is org.eclipse.ui.internal.dialogs.EditorsPreferencePage. That's where you set other Editor CTabFolder prefs, like "Show multiple editor tabs" http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/tree/bundles/org.eclipse.e4.tools.orion.css.editor/src/org/eclipse/e4/tools/orion/css/editor/CSSEditorPreferences.java#n94 is an example of how to get the existing CSS (at least the main CSS page). http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/tree/bundles/org.eclipse.e4.tools.orion.css.editor/src/org/eclipse/e4/tools/orion/css/editor/CSSEditorPreferences.java#n164 is an example of how you write out a modified CSS page and save it as a modified theme. PW
(In reply to Paul Webster from comment #78) I would challenge the wisdom of the decision to make MRU behavior controlled by CSS. Instead of writing a preference page that modifies CSS, it's better to make MRU behavior controlled by a regular preference and remove it from CSS.
(In reply to Paul Webster from comment #78) > (possibly) helpful notes: > > The editor preference page is > org.eclipse.ui.internal.dialogs.EditorsPreferencePage. That's where you set > other Editor CTabFolder prefs, like "Show multiple editor tabs" > > > http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/tree/bundles/org. > eclipse.e4.tools.orion.css.editor/src/org/eclipse/e4/tools/orion/css/editor/ > CSSEditorPreferences.java#n94 is an example of how to get the existing CSS > (at least the main CSS page). > > http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/tree/bundles/org. > eclipse.e4.tools.orion.css.editor/src/org/eclipse/e4/tools/orion/css/editor/ > CSSEditorPreferences.java#n164 is an example of how you write out a modified > CSS page and save it as a modified theme. > > PW Super! Thanks Paul. Definitely helpful :)
(In reply to Andrey Loskutov from comment #76) > > Why not make both groups happy by making it a preference? > > IMHO this is *must have* requirement fot the proper fix for this bug. +1, IMHO adding the preference *is* the main focus of this bug. As Doug mentioned, we can argue all day long (or for the past 10 years, bug 68684), but we can never make everyone happy with the default setting. Therefore we clearly must have an easily accessible preference for switching. (In reply to Sergey Prigogin from comment #79) > (In reply to Paul Webster from comment #78) > I would challenge the wisdom of the decision to make MRU behavior controlled > by CSS. Instead of writing a preference page that modifies CSS, it's better > to make MRU behavior controlled by a regular preference and remove it from > CSS. Better yet, make it a preference and use a variable substitution in the CSS.
(In reply to Sergey Prigogin from comment #79) > (In reply to Paul Webster from comment #78) > I would challenge the wisdom of the decision to make MRU behavior controlled > by CSS. Instead of writing a preference page that modifies CSS, it's better > to make MRU behavior controlled by a regular preference and remove it from > CSS. No, it will remain as CSS for sure. PW
(In reply to Cole Markham from comment #81) > > Better yet, make it a preference and use a variable substitution in the CSS. This would be possible if we go forward with the work for bug 422536, although I'm not really sold on making it a preference. Just append the correct incantation of CSS based on the pref page checkbox, and scan for it on startup (would be my preferred option, but I'm open to others). PW
The work has already been done, https://github.com/jeeeyul/eclipse-themes, and it's EPL code. Maybe we should just look at including that as part of the default install.
(In reply to Paul Webster from comment #82) > No, it will remain as CSS for sure. Could you please elaborate on the rationale for this opinion.
(In reply to Sergey Prigogin from comment #85) > > Could you please elaborate on the rationale for this opinion. That discussion is 1) implementation for which we've picked CSS and 2) long over. Doug's exploring making it available to users, that the backend is CSS will then no longer trouble them. PW
(In reply to Cole Markham from comment #84) > The work has already been done, https://github.com/jeeeyul/eclipse-themes, > and it's EPL code. Maybe we should just look at including that as part of > the default install. They did explore asking him to contribute it, but it kinda petered out. Also, it works differently than how we modify our CSS. PW
(In reply to Paul Webster from comment #83) > (In reply to Cole Markham from comment #81) > > > > Better yet, make it a preference and use a variable substitution in the CSS. > > This would be possible if we go forward with the work for bug 422536, > although I'm not really sold on making it a preference. On further research, that bug is about setting appearance related preferences (like the font or color preferences of the java editor), not about consuming preferences. PW
I certainly haven't got used to CSS style preferences. I always thought CSS was for styling. I'm sure that's what one of the S's stand for. But I'm old school and maybe the kids have a better idea. One of the reasons I would like this a preference is so I can set it in my plugin_customization.ini for my product builds? Is there a CSS'y way to get the same result?
(In reply to Doug Schaefer from comment #89) > One of the reasons I would like this a preference is so I can set it in my > plugin_customization.ini for my product builds? Is there a CSS'y way to get > the same result? No, but there are a couple options: 1) if you are providing a product/plugin_customization.ini then you can choose which CSS theme is used and provide your own CSS theme and you get to set the defaults there. A customized CSS theme doesn't have to be much more than: @import url("platform:/plugin/org.eclipse.ui.themes/css/.appropriate css file"); #org-eclipse-ui-editorss CTabFolder.MPartStack { /* set MRU */ swt-mru-visible: true; } 2) back to bug 422536 and you a) create the MRU preference b) we can then set it in the style sheet c) you have to make sure that the MRU pref + swt-mru-visible: interact in some useful way 3) enhance bug 422536 even more and allow CSS to read a preference. Then the style sheet can specify swt-mru-visible: 'some-pref-value-identifier' and it would get picked up. PW
(In reply to Paul Webster from comment #90) > 1) if you are providing a product/plugin_customization.ini then you can > choose which CSS theme is used and provide your own CSS theme and you get to > set the defaults there. This doesn't work due to bug 408922.
(In reply to Sergey Prigogin from comment #91) > > This doesn't work due to bug 408922. When specifying a product you specify the default theme in plugin.xml PW
Are we sure users would expect behavior such as this to be part of a theme? What's the setting of this in the Dark theme? What if my users like the dark theme better than my product theme (and I do have a product theme controlling colors and such). Do you really think they'll understand that the theme controls behavior like this. At the very least I should have product specific css settings that are independent of the visual theme css. If that's not there, then this needs to be a normal preference.
(In reply to Doug Schaefer from comment #93) > Are we sure users would expect behavior such as this to be part of a theme? But users would get the pref on the pref page. Customizing it using plugin_customization.ini or a product CSS is packagers, not users. PW
(In reply to Paul Webster from comment #86) > > Could you please elaborate on the rationale for this opinion. > > That discussion is 1) implementation for which we've picked CSS and 2) long > over. I don't find this explanation satisfactory. Themes are for appearance. Using them for controlling behavior violates user expectations.
(In reply to Doug Schaefer from comment #93) > Are we sure users would expect behavior such as this to be part of a theme? > What's the setting of this in the Dark theme? What if my users like the dark > theme better than my product theme (and I do have a product theme > controlling colors and such). Do you really think they'll understand that > the theme controls behavior like this. > > At the very least I should have product specific css settings that are > independent of the visual theme css. If that's not there, then this needs to > be a normal preference. I absolutely agree. I think the best option is 3 from comment #90 above: >3) enhance bug 422536 even more and allow CSS to read a preference. Then the style sheet can specify swt-mru-visible: 'some-pref-value-identifier' and it would get picked up. This makes it a real preference, and if themes want to present MRU in different way to users then they can use the user's preference of whether they want the behavior or not. Thus, the behavior stays the same regardless of the theme selected. Unless, of course, you select a theme that changes the behavior without respecting the user's preference (like a copy of the current theme).
(In reply to Sergey Prigogin from comment #95) > > I don't find this explanation satisfactory. Themes are for appearance. Using > them for controlling behavior violates user expectations. Arguably you're not wrong. Moving to a policy based option as mentioned in comment #44 will move it out of a CSS property and the purvue of a preference completely, and into being specified in the model (or specified as a modifier in the CSS, similar to the CTabRenderer today). The closest open bug I could find was Bug 168379 which was repurposed for an editor management policy for Eclipse4. But that's not going to be implemented in Luna, so CSS it is. PW
(In reply to Paul Webster from comment #97) > (In reply to Sergey Prigogin from comment #95) > > > > I don't find this explanation satisfactory. Themes are for appearance. Using > > them for controlling behavior violates user expectations. > > Arguably you're not wrong. Moving to a policy based option as mentioned in > comment #44 will move it out of a CSS property and the purvue of a > preference completely, and into being specified in the model (or specified > as a modifier in the CSS, similar to the CTabRenderer today). The closest > open bug I could find was Bug 168379 which was repurposed for an editor > management policy for Eclipse4. > > But that's not going to be implemented in Luna, so CSS it is. > > PW So are you saying that if I implement this as a normal preference you'll reject my patch? How about this deal, I'll implement it as CSS if I'm allowed to turn on MRU by default. I really don't want my product to have non-MRU behavior ever, no matter what theme is turned on.
(In reply to Sergey Prigogin from comment #95) > Themes are for appearance. Using > them for controlling behavior violates user expectations. So, when I said this, back in comment #15, more than one year ago I was not so fool! ;-)
(In reply to Mauro Molinari from comment #99) > (In reply to Sergey Prigogin from comment #95) > > Themes are for appearance. Using > > them for controlling behavior violates user expectations. > > So, when I said this, back in comment #15, more than one year ago I was not > so fool! ;-) :). There were a lot of things said between #1 and #80 or so that we probably regret, but you are right on the money with that one. Mind you I don't mind so much the CSS settings for everything, but you can't move all preferences to CSS stylesheets unless you provide a mechanism that allows products to override the settings. I can have multiple stylesheets in my HTML pages. There should be a way to do that with Eclipse. I'd be surprised if the gang didn't think of that since that would be a regression and will dig into it more.
(In reply to Doug Schaefer from comment #98) > (In reply to Paul Webster from comment #97) > > So are you saying that if I implement this as a normal preference you'll > reject my patch? Yes. I'd accept it as a preference if we had the proper pref-css support, but that doesn't look like it would work for Luna (although I heard that Brian de Alwis might look at that today or tomorrow). > > How about this deal, I'll implement it as CSS if I'm allowed to turn on MRU > by default. OK, deal. We can turn the MRU back on for all of the style sheets we have in org.eclipse.ui.themes and you (with some help from us) can provide a checkbox on the appropriate preference page that works through CSS. PW
Uh, hmmm, StackRenderer.getInitialMRUValue(). Y'all knew this was done already, no? CSS variable 'swt-mru-visible' and all that?
Oh, for crying out loud. That's why I saw mru set to true. It's actually turned on in our product theme (momentics.css). And it's working fine right now. WTF! It is nice though, you should all be turning it on ;p. But the point does stand, there's no UI to turn this on for people who don't have it on. And there's now way for a product to override this setting for all themes. But that may be a bigger problem. And, I will certainly run into it as we try the dark theme in Momentics where I'll want this setting independent of that. But I am curious why I ran into it the other day. There may still be a bug lurking there.
Ah, I had the Mac theme turned on and that's why I saw it. Which just highlights how illogical it is that this setting is tied to the visual theme (Sergey's right again :) )
Doug, can we expect a fix for M7?
No fix for M7. After testing, I'm actually finding that MRU is working fine, so it's less urgent. The question becomes bigger. It's how whether this setting should be part of a theme (which makes no sense to me), and if so, are there ways products can override the settings in a theme. I think 4.5 is a better place for this so we can revisit the whole options/theme thing. Too bad we'll have to wait a whole year though. For my product needs, I may need to fork the platform again and get this in.
The pain finally got bad enough to go searching for other sufferers. +100 for making MRU the default in every style +10 for making it hard to change to the indescribable way it works now. Although I have skimmed, this discussion thread looks like something out of Kafka. I am thankful for this: http://stackoverflow.com/a/12642761/541202
The stack overflow comment is more ammunition that it's crazy that settings like this are tied to a theme. It's not how average users think. I'm also suspicious that average users want the non-MRU behavior. Certainly a vocal few want it, but either way, it's got to be easier to change it independent of the theme. This is still high on my radar to figure out. And will be higher when I get our product on the Luna and start using the Dark theme. But that won't be until the summer.
As an Eclipse user for most of the last decade I'll go on record saying I have no idea how anything other than MRU is useful. For the past few years I've been completely baffled by what the set of shown tabs on my window is, and as such have completely given up on ever clicking them and use keyboard shortcuts to type in the name and go directly to it every time. Now I know why. Set the default to MRU, IMO.
It's really starting to feel that more people want MRU than not. I'd be happy to take another look and submit a change to make that the default for Mars.
(In reply to Doug Schaefer from comment #110) > It's really starting to feel that more people want MRU than not. I'd be > happy to take another look and submit a change to make that the default for > Mars. Yes, we still want this for Mars, but we want a preference so that people can choose what they want.
And the default will have to go back to MRU. Comment 0 tells why. Nobody could give a justification [1] why the current E4 behavior should be preferred, so it should never have been the default. [1] To set the requirements clear: A justification is a self-contained, consistent, and short explanation; not a reference to a multi-page pong-pong bug.
(In reply to Markus Keller from comment #112) > And the default will have to go back to MRU. If I get a contribution that offers a checkbox on the pref pages but modifies the the CSS (the architecture moving forward) I said I'd accept it and we would switch to MRU in the default. We might be able to find a similar way forward. PW
(In reply to Paul Webster from comment #113) > (In reply to Markus Keller from comment #112) > > And the default will have to go back to MRU. > > > If I get a contribution that offers a checkbox on the pref pages but > modifies the the CSS (the architecture moving forward) I said I'd accept it > and we would switch to MRU in the default. +1, that's what I tried to say with comment 111.
*** Bug 438312 has been marked as a duplicate of this bug. ***
(In reply to Paul Webster from comment #113) > (In reply to Markus Keller from comment #112) > > And the default will have to go back to MRU. > > > If I get a contribution that offers a checkbox on the pref pages but > modifies the the CSS (the architecture moving forward) I said I'd accept it > and we would switch to MRU in the default. > > We might be able to find a similar way forward. > > PW OK, will get to that soon. Marking for M2 for now.
Yes, won't get this for M3. But it certainly is bugging a lot of people in the community lately. The editor tabs as they are right now are really useless. There have been strong opinions on this in the past to keep the status quo, but unfortunately that has led us down a bad path. The bigger thing though is that the list under the chevron is in a horrible order even with MRU. Would be great if we could order it alphabetically or something that would make it easy to find the editor you're looking for. Unfortunately though, the order seems to be the tab order, which brings up a disturbing fact that the order isn't even controlled by the workbench, but the order of the tabs in the CTabFolder in SWT. Not sure how we can get higher order control of that. Probably need another UI control to take the role of the chevron. OR just change the editor tab paradigm completely.
(In reply to Doug Schaefer from comment #117) > Probably need another UI control to take the > role of the chevron. OR just change the editor tab paradigm completely. YES, long term. But for now, pls don't get carried away; didn't we just want a preference option to toggle MRU behavior? See all that great agreement in comment 110 (Doug), comment 111 (Dani), comment 112 (Markus), comment 113 (Paul), comment 114 (Dani).
Uh, yeah. I want to make sure we have an end vision before we spend too much time on the short term solution. At the very least, we do need a mechanism to turn on MRU. I'm just concerned that even that doesn't help all the time.
(In reply to Stephan Herrmann from comment #118) > > But for now, pls don't get carried away; didn't we just want a preference > option to toggle MRU behavior? See all that great agreement in comment 110 > (Doug), comment 111 (Dani), comment 112 (Markus), comment 113 (Paul), > comment 114 (Dani). Yep. I stumbled again on this bug recently and can only agree with that. Disclaimer ########## Some of you might know that I'm the passionate MRU hater from bug 68684 day one. I even wrote plugin (http://marketplace.eclipse.org/content/extended-vs-presentation) which offers different (MRU free) tab management for 3.x Eclipse. So I heavily biased and definitely not a friend of reintroducing MRU by default in Eclipse as this bug requests. But (!) despite this I want see the current bug solved and would like to propose a compromise solution. So let's reiterate what we've learned from bug 68684 and bug 388476. Problem statement ################# Common for this bug and original bug 68684 is that people want have control over the tab placing/reordering strategy. Users don't want that someone decides for them which way they should organize tabs and they don't want to have behavioral things (tab reordering strategy) be dependent on visual design choices (CSS themes). Additionally the amount of voters and commentators on both bugs clearly shows that this *is* a real world issue which needs an urgent solution. Discussion summary ################## Reading carefully this bug comments we see following main points: 1) Strong request from users for the preference option controlling the MRU. 2) Strong request from users not to couple MRU behavior with themes (behavior vs appearance), which is contradictory to the next point below. 3) Strong opinion from Paul (comment 12, comment 14, comment 28, comment 82, comment 97, comment 101) that he (as Platform UI lead) will not accept patches for this issue if they would not provide proper CSS support for preferences. 4) Lack of resources and time and might be even lack of interest to implement patch as requested in point 3) above. Success criteria ################ The points above (except 4) are also the success criteria for the fix of this issue. 1) users can control the MRU behavior. 2) MRU behavior is not affected by switching visual themes. 3) chosen solution is consistent with the long term design goals of Platform UI. Reality ####### Let's face the facts: 4 years after introduction of the issue with 4.x stream the bug is still not going to be fixed in the "right way" in 4.5. The main problem is that Platform UI has no resources for that and others have most likely not enough experience with e4 CSS engine to provide the "right fix" which can be accepted. This dilemma simply means that this bug will never be fixed ... unless we can find a compromise. Therefore I personally think that we *must* find a *practical* compromise solution to make our users happy. We can't delay the fix for years! Compromise proposal ################### The ultimate goal of the compromise is to make the users happy :-) The compromise proposal tries to make everyone happy, but as with every compromise each side must make some concessions. Platform UI concession (I hope) could be to accept the patch which does not (yet) adds CSS preferences support - but I think that this proposal does not close the doors for it later. My personal concession (which isn't important however) is that MRU is on by default :-) Proposal in short: - MRU is set to "true" by default via preferences (can be changed by product owners). - MRU is controlled by users and is not affected by themes switch by default (can be changed by product owners). - Long term vision is not broken, the implementation underneath can be changed without affecting user experience later. Proposal details: 1) Introduce global switch to control if CSS (themes) or preferences (user) are controlling the MRU functionality. Per default (as long as there are no "right fix") MRU behavior will controlled by preferences, independently what the CSS themes says, so that switching CSS themes does not affect the actual MRU value. This solves 1) and 2) goals. The benefit is that no themes must be changed and the user experience is consistent from day one. 2) As soon as someone implements the "right fix" - preferences support for CSS themes, the implementation can be easily changed to control MRU by CSS (either via preference or via code). This solves goal 3). 3) Add preferences which can allow all involved parties (with different opinions on MRU/solution) to control the desired behavior on the product level. This allows all involved parties "keep the face" and makes the compromise actually possible. 3 preferences for the "org.eclipse.e4.ui.workbench.renderers.swt" instance are added: - "mruControlledByCSS": if the MRU behavior should be controlled via CSS or preferences. Default will be "false" now. - "enableMruDefault": what should be considered as default MRU value if this is controlled by preferences. Default will be "true" now. - "enableMru": what should be considered as actual MRU value if this is controlled by preferences. This preference can be changed by user if the "mruControlledByCSS" is "false". Only the last preference is exposed to users by new "Enable most recently used order for tab placement" checkbox on the "General->Appearance" page (see screenshot). The default value is "true" and corresponds to the "enableMruDefault" preference above. If "mruControlledByCSS" is "true", this checkbox is not visible to user - the assumption is that the "right fix" (live theme editor or something similar) will provide all required settings and take control over the MRU behavior. Important: if product owners want to keep on current behavior, they can revert the effect of all proposed changes by specifying "mruControlledByCSS=true" in the plugin_customization.ini. I hope with this compromise proposal we can fix the current bug in 4.5 time frame. Gerrit patch follows.
New Gerrit change created: https://git.eclipse.org/r/41877
Created attachment 250804 [details] Proposed checkbox for MRU Fix: https://git.eclipse.org/r/41877
Thank you so much. Your analysis is spot on. Surfacing this choice so it can be found by searching preferences is really key.
(In reply to Andrey Loskutov from comment #120) > > I hope with this compromise proposal we can fix the current bug in 4.5 time > frame. It looks like a good direction, thanks Andrey. PW
Most excellent! Thanks Andrey. This will definitely help us for now. My biggest fear is that even with this setting turned on, it's not going to help. When you have 20 editors open it's just really hard to keep track of them all with our current UI paradigm, i.e. tabs. Not sure what's better, but we should revisit this once we get a few other things fixed up.
Platform committers (and interesting contributors), please, can we start with the review? It would be great if we could review and merge before M6 to get more chances for feedback before the changed behavior to the release.
Created attachment 251183 [details] Screenshot for mru settings if CSS themes are disabled I was completely unaware of the fact that CSS theming can be disabled via "-cssTheme none" command line argument (just another argument to separate CSS visuals from behavior). This undocumented feature allows user to run Eclipse 4.x absolutely "CSS-free" - unfortunately this caused the problem that ALL settings on the "Appearance" preferences page were entirely disabled (including non-CSS related). The last patchset (https://git.eclipse.org/r/#/c/41877/4) provides also fix for this case. The attached screenshot shows the preferences page if "-cssTheme none" is specified.
Gerrit change https://git.eclipse.org/r/41877 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ead0d552a9cadb8b02bab895e18c51a8c78a2235
Thank you, Andrey.
Please review M6 release notes: https://git.eclipse.org/r/42972
This causes Javadoc problems in the build: http://download.eclipse.org/eclipse/downloads/drops4/N20150301-2000/compilelogs/platform.doc.isv.javadoc.txt ../../../eclipse.platform.ui/bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/StackRenderer.java:29: error: package org.eclipse.e4.core.di.extensions does not exist import org.eclipse.e4.core.di.extensions.Preference; ^ ../../../eclipse.platform.ui/bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/StackRenderer.java:151: error: cannot find symbol @Preference(nodePath = "org.eclipse.e4.ui.workbench.renderers.swt") ^ symbol: class Preference location: class StackRenderer 2 warnings The discouraged reference to the non-API type "Preference" will also be reported in the build. If accessing these internals is really the right thing to do, then see https://wiki.eclipse.org/index.php/How_to_add_things_to_the_Eclipse_doc Adding this at line 165 of platformOptions.txt should do it: ;${eclipse.platform.runtime.bundles}/org.eclipse.e4.core.di.extensions/${dot.classes}
(In reply to Markus Keller from comment #131) > This causes Javadoc problems in the build: > http://download.eclipse.org/eclipse/downloads/drops4/N20150301-2000/ > compilelogs/platform.doc.isv.javadoc.txt I've created bug 461198 to track this.
The preference name sounds a bit clumsy and doesn't tell what the alternative is (random order?). How about a label and a Combo: Tabs visible on overflow: [Most recently used] [Sliding window in opening order] I can't really give a good name for the non-MRU order, since I don't understand its use case. Added "MRU" as preference page keyword: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=dcb60986d5821bac9d8153130ea4a8e98938ff5f
Thanks also from my side Andrey. The only issue I see is that we now changed the default back to "true" for MRU. I know this is controversial but our Eclipse 4 default themes had MRU of and we should not lightly change that. I created Bug 461736 to track this.
Verified in I20150318-2000
(In reply to Mike Mike from comment #136) > Anyone knows where it is possible? > > Any official site available ? > > https://… [redacted] Is there a way to report the previous comment as spam?
(In reply to Didier Loiseau from comment #137) > (In reply to Mike Mike from comment #136) > > Anyone knows where it is possible? > > > > Any official site available ? > > > > https://… [redacted] > > Is there a way to report the previous comment as spam? See bug 549474.
