Community
Participate
Working Groups
R3.3 and I20071023-0800. The General > "Keep next/previous editor, view and perspectives dialog open" preference is hard to understand. This was already pointed out some time ago by Julian, see bug 60506: " 3) Keep next/previous part dialog open - Julian mentioned this was particularly confusing. Perhaps it should be moved to the "Appearance" preference page? It doesn't seem to deserve a prominent place. " Besides confusion there are two obvious bugs: 1. those aren't dialogs (rather quick views) 2. it should use plural for 'editor' and 'view' as well AFAIK the preference only affects the behavior when using the key binding. Hence we could change the preference to something like: Close next/previous navigation popup when key binding is released.
Agree, not at all clear what its requesting. And the fact its on the first pref page could imply its important to a new user.
And we could also add "No popup".
> AFAIK the preference only affects the behavior when using the key binding. Shouldn't it be moved to the keys preference page then? E.g. into the "Advanced" dialog, which should have a different title and a named Group anyway. My label proposal: Keep 'Next *' and 'Previous *' navigation pop-ups after all keys released
(In reply to comment #2) > And we could also add "No popup". That would need another feature request, since it is not just a cosmetic change. We would have to decide how this should work exactly (e.g. only allow to go to next editor but not to next-next, or allow riding through multiple editors while the modifier is held down).
(In reply to comment #3) > > AFAIK the preference only affects the behavior when using the key binding. > > Shouldn't it be moved to the keys preference page then? E.g. into the > "Advanced" dialog, which should have a different title and a named Group > anyway. Its not a preference on a keybinding though, it just happens to be a command that is invoked solely by keysequence. If we had a Navigation or Interaction page then it'd go there, but we don't, and I don't see anything other than "Open Mode" to move there. Or we could grow a "Miscellaneous" page with this option and "Show Heap Status" from the General page. This at least would correctly categorize them from being General, which they aren't (seems General is just the place we put things we didn't know where else to put, hence "Misc"). >>Keep 'Next *' and 'Previous *' navigation pop-ups after all keys released How about Keep 'Next *' and 'Previous *' navigation pop-ups open after key released
> Its not a preference on a keybinding though, it just happens to be a command > that is invoked solely by keysequence. Nope, see Window > Navigation > Next Editor. > How about > Keep 'Next *' and 'Previous *' navigation pop-ups open after key released The important point is IMO that the preference affects the behavior when *all* keys (or the *last* key, or the *modifier* key(s?)) are released.
How many on this planet actually enable this preference i.e. could we simply drop it?
> How many on this planet actually enable this preference i.e. could we simply > drop it? +1 for dropping (and at the same time making sure that those who did enable the checkbox are not stuck with that option but get the default behavior afterwards).
> > Its not a preference on a keybinding though, it just happens to be a command > > that is invoked solely by keysequence. > > Nope, see Window > Navigation > Next Editor. > > The important point is IMO that the preference affects the behavior when *all* > keys (or the *last* key, or the *modifier* key(s?)) are released. Sorry I didn't write that well. Its a modifier/preference on a command when invoked from the keyboard, almost like its another command because the behaviour changes. If I had a Navigation preference page, and the Keybindings one, I believe I'd think to look in the former not the latter, because its a modification of how that command works. The only other case I know of where keysequence and menu result in different behaviour is Print in most MS apps, where one results in the print dialog and the other doesn't. If we were to accumulate more of these I don't think they'd all be piled into the keybindgs pref, again since they're really just options on the commands IMHO. But in any case this discussion just brings home the point of how confusing this option is. I actually had no idea it existed until this bug report. I'd be ok with dropping but the one utility I can see is accessibility: it can be very difficult to maintain keydown while doing some other keysequence for someone with motor skills problems, and this command in particular might be quite useful for that group. So if we were to remove the option then I'd argue the "default" would be to have the option on. But I can hear the screams of protest already. Thus unfortunately I think we need to keep it.
Kevin, I agree that 'Keys' would not be a good place but I disagree with your accessibility assessment: a person who has trouble holding the modifier while pressing the Up or Down arrow key will most likely also not be able to easily hit Ctrl+F6. He might then change it to e.g. F6 in which case there is no modifier at all involved and hence the dialog never auto-closed no matter what the preference is (clever, isn't it). So, my vote is still to remove that preference.
(In reply to comment #10) > Kevin, I agree that 'Keys' would not be a good place but I disagree with your > accessibility assessment: a person who has trouble holding the modifier while > pressing the Up or Down arrow key will most likely also not be able to easily > hit Ctrl+F6. He might then change it to e.g. F6 in which case there is no > modifier at all involved and hence the dialog never auto-closed no matter what > the preference is (clever, isn't it). So, my vote is still to remove that > preference. It depends though on what accessibility assistance you have at the OS level. In WinXP, if I turn on "Sticky Keys", then I can - press Control, - release it, - press F6 each as single key downs with no holding. The editor chooser appears correctly (yeah!) but of course disappears immediately because Sticky Keys can't help us here (boo). So I *have* to use our pref, or as you outlined, define my own key sequence. As an aside, the more I think about this option, the more I find it to be bad. It doesn't lend itself easily to accessibility, and as you note it behaves differently as soon as you bind it to a different key sequence. I don't care for a solution that says that to make it accessible you need to define a new keybinding because that *happens* to turn off the behaviour. First off its very difficult to know. Second, people should be able to keep the same keybindings while improving accessibility, so that among other things someone can sit down to work with the person with accessibility needs and mostly the UI behaves the same way.
>WinXP, if I turn on "Sticky Keys", then I can Right - forgot about this. Not sure whether this could be detected - if so, we could simply enable the behavior if this support is enabled. Assuming there are other accessibility related UI preferences and hints we could add an 'Accessibility' preference page. There's already one for Text Editors. And/or we document it on: org.eclipse.platform.doc.user/concepts/accessibility/accessmain.htm
Removing 3.5 target milestone. We are in the end-game now. Please have a look and decide if this should be targeted at 3.6.
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.
