Bug 34602 - Infopop should be on mouse position, not on focus part
Summary: Infopop should be on mouse position, not on focus part
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2003-03-11 09:41 EST by Martin Aeschlimann CLA
Modified: 2004-05-25 12:05 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Aeschlimann CLA 2003-03-11 09:41:08 EST
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?
Comment 1 Dorian Birsan CLA 2003-03-11 10:02:24 EST
The UI component handles F1 triggers.
Comment 2 Andrew Irvine CLA 2003-03-11 14:51:21 EST
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.
Comment 3 Nick Edgar CLA 2003-03-12 01:14:39 EST
Moving it to the mouse location would not be accessible.
Comment 4 Martin Aeschlimann CLA 2003-03-12 08:32:13 EST
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'
Comment 5 Nick Edgar CLA 2003-03-12 14:43:34 EST
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.



Comment 6 Nick Edgar CLA 2003-03-12 14:44:27 EST
Moving to Help to consider placement of the infopop.
Comment 7 Dorian Birsan CLA 2003-03-12 15:02:30 EST
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.
Comment 8 Nick Edgar CLA 2003-03-12 15:44:48 EST
OK, will consider for 2.2.
Comment 9 Michael Van Meekeren CLA 2004-05-25 12:05:31 EDT
The keyboard focus should take priority over mouse in general, this is also an 
accessibility requirement