Community
Participate
Working Groups
20030307 The behaviour that F1 opens help for the widget in focus is not intuitive. It should be for the control where the mouse pointer currently is. Most controls also never can get the focus, e.g. how can I get the help for a toolbar button?
The UI component handles F1 triggers.
Help is associated with cursor focus, not mouse focus. The info pop-up should follow the mouse, else you will get random pop-ups where you are not looking, which would also be confusing.
Moving it to the mouse location would not be accessible.
Suggest to reopen. The infopop feature in it's current form is too bad. Because the infopop pops up at the location of the mouse, you would expect it to be the help for the location of the mouse. So maybe if it pops up at the location of the control in focus, the problem would be solved. Please try this scenario: 1. Start eclipse on a new workspace. 2. The welcome page is opened 3. Move the mouse over the 'New wizard' button in the toolbar Note, the button gets a 3d 'focus' rectangle around it 4. Press F1 The help text says 'A quick, simple guide to introduce new users to some basic tasks.' The infopop is at the location of the button, the button has a 3d 'focus' rectangle around it but the help is about the 'welcome editor'
I agree this case is confusing. There is an existing PR about toolbar buttons not handling F1 help: bug 20226. This is an SWT limitation. Other apps just bring up the overall application help in this case. Some apps support Help / What's This? For us, it would be less confusing if the infopop appeared closer to part to which it applies, rather than the pointer location.
Moving to Help to consider placement of the infopop.
Nick, help exposes the following APIs IHelp.displayContext(IContext context, int x, int y) IHelp.displayContext(String contextId, int x, int y) that the UI component calls with the appropriate (x,y) coordinates. It is in the UI that F1 is handled and the infopop is launched with one of the above two API's. Since the infopop will be positioned according to the given parameters (x, y), there isn't much else we can do. I'd suggest we move this bug to the UI component and discuss other alternatives.
OK, will consider for 2.2.
The keyboard focus should take priority over mouse in general, this is also an accessibility requirement