Community
Participate
Working Groups
3.3 M7 / Linux / GTK Eclipse currently has far too many ways to switch editors. The new "Quick Access" command can do everything the older "Quick Switch to Editor" command could. We should remove the older command in order to free up a keybinding and remove clutter from the keybindings page. Its ID should be redirected to the new command, in case there is downstream code that is referring to it. Note: Every time something gets removed from the UI, someone will complain. This will be no exception. Please have the courage to resist. The new command is better than the old, and users will learn to adapt.
Here here.
See bug 181189 - it was asking for the exact opposite, with an explanation why Quick Access is not better than Quick Switch Editor in all possible ways.
I do not feel that bug 181189 makes a strong case for keeping the old behavior. The fact that some people liked the old behavior is inevitable - it is not a reason to avoid improving the UI. If users want quick access to editors only, they can use JDT's ctrl-shift-T. There will be theoretical cases where quick access will result in more hits than the old action would have (such as a file called New.java), but these are going to be quite rare in the real-world (*). Even in these rare cases, the quick access feature puts editors at the top, so you can still select the editor you wanted in the same number of keystrokes. (*) The probability of this happening is about the same as the probability of a collision in the a small set of random strings of that length, which isn't too likely for the set sizes we deal with.
Why can't we just have the quick access dialog come up in the editor showing only the available editors by default? If the user hits the keybinding again it will show everything and will remember that choice. If activated outside of the editor area you get the current behavior. Essentially make it parameterized with the parameter being "editors" when invoked from the editor area.
> Why can't we just have the quick access dialog come up in the editor > showing only the available editors by default? If the user hits the > keybinding again it will show everything and will remember that choice We could, but that's making it less powerful and more complicated (more complicated due to the extra mode). As long as editors are always shown first in the list, it shouldn't matter if we're also showing additional things farther down. Someone who was used to the old keybinding should still be able to get to their editor in the same number of keystrokes as they did before and we don't need to remove any power from the quick access key.
...in other words, I think quick access should continue to work exactly like it does now. It's a fantastic usability improvement and I'd hate to see it watered down.
I think it's too late to be messing with this in 3.3. Maybe in 3.4 we can remove one or more of the old ways to switch editors...
why remove features that are useful and people are accustomed to? cant it be less drastic? i think the keybinding clutter is a valid point but i guess it would just suffice to remove the keybindings of older features and explain in N&N why. interested user would still to be able to just reconfig the keybindgs to the old feature/command.
I don't have plans to remove this in 3.5... not enough energy at this time to fight the good fight.
> why remove features that are useful and people are > accustomed to? cant it be less drastic? Every feature needs to be maintained, which takes developer time away from doing useful things. In this case, the feature is not useful because it has been replaced by something more powerful. There is no good reason to keep the old feature. Every feature needs to be documented, and having many ways to do the same thing just clutters the docs and adds user confusion. > i think the keybinding clutter is a valid point but i guess it would > just suffice to remove the keybindings of older features and explain in > N&N why. interested user would still to be able to just reconfig the > keybindgs to the old feature/command. Even if we weren't wasting a valuable keybinding (which we are), we'd still be adding clutter to the keybindings page. If there are three different ways of switching editors, then a user wanting to bind a key to "switch editor" will see three different similarly-named choices in the preference page without being given any guidance as to why they should choose one over the other. In this case, one choice is always better... so let's not even give the user the option of making the wrong choice.
(In reply to comment #10) > Every feature needs to be maintained, which takes developer time away from > doing useful things. In this case, the feature is not useful because it has > been replaced by something more powerful. There is no good reason to keep the > old feature. sorry, but it is ur subjective opinion that the feature is not useful. other user might content otherwise. > ... In this case, one choice is always better... > so let's not even give the user the > option of making the wrong choice. i disagree. i just found out that about ctrl+3 via this issue and like it and am using it as of now. but to generalize that one option is always better is a far stretch which I will oppose. diff. people like diff things and if the functionality is already there i would vote to keep anyways in favor of those that got used to it -- unless, the maintenance of the code is really a big deal. (i know, many little things add up too). further, nothing bad happens really when the "wrong" dialog pops up or the user doesnt work as efficient as he could, or rather, how you would do it. in regard to protecting the user from too many choices: that's a worry Microsoft has to take into consideration -- but developers, which i consider power users, should really have no problem here.
> sorry, but it is ur subjective opinion that the feature is not useful. > other user might content otherwise. The new binding can do everything the old one could, and that it can do so in the same number of keystrokes. The new binding is capable of doing more things than the old one could. This means there is no efficiency benefits nor any functionality benefits of the old binding over the new one. What part of this do you believe to be just my opinion? That's retorical, really. Anyone can count keystrokes or observe the functionality coverage of the binding. When something is easily measureable and reproducable by a third party, we refer to it as a "fact" - not "just your opinion".
Remy is now responsible for watching bugs in the [QuickAccess] component area.
(In reply to comment #12) > > sorry, but it is ur subjective opinion that the feature is not useful. > > other user might content otherwise. > > The new binding can do everything the old one could, and that it can do so in > the same number of keystrokes. The new binding is capable of doing more things > than the old one could. it has been a while since i commented last on it and some time has gone by and i still find that i use this command over the more general albeit more capable "Quick Access". Reason: with this command the scope is preset to just editors, the QA command has a general scope, hence i have to use more keystrokes to disambiguate what i'm wanting. as a suggestion and compromise: maybe there is a way of splitting the QA command into sub commands which use the same functionality of the QA Command but have their scope preset. E.g. u would still have a Command Quick Access that works as now, but u also would have Quick Access Editors, QA Views, Persectives and so on. That way i would be able to bind my key stroke that i have assigned to Quick Switch Editors to QA Editors and be happy. somewhere else, but i cant find the issue anymore, i have commented regarding quick access, that it would be great to allow for a special char sequence @ the start to set the scope, e.g. "e: " to set the scope for editors. note also the ideas i put down here https://bugs.eclipse.org/bugs/show_bug.cgi?id=53850#c9
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
