Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 27397

Summary:	[Workbench] Aim has to be too good
Product:	[Eclipse Project] Platform	Reporter:	Jeff McAffer <jeffmcaffer>
Component:	UI	Assignee:	Tod Creasey <Tod_Creasey>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	P5	CC:	gunnar, narendra_gundkal
Version:	2.1	Keywords:	helpwanted
Target Milestone:	---
Hardware:	PC
OS:	Windows 2000
Whiteboard:

Description Jeff McAffer

2002-11-29 10:32:33 EST

There are many places in the UI where my aim with the mouse has to be too 
good.  This seems to be a general usability issue.  Perhaps I am getting old 
but here are some that come to mind.

- sashes are about one pixel wide.  Often you get the mouse lined up so the 
cursor changes and then press the button and find that you have missed the 
sash.  In some cases you have moved the mouse but I experimented and now 
believe that the hot area for cursor change and the actual location of the sash 
are not lining up.  This is true of fastview resizing as well.

- check boxes/radio buttons.  The UI is inconsistent here.  Sometimes you can 
click on the text label beside these and sometimes you can't.  More often than 
not the user has to click actually in the box/button.  This inhibits fast work.

- Perhaps a JDT UI problem but the bar down the right side of an editor which 
shows the overview of where you problems are is *very* fine grained.  The error 
bars generally seem to be about one pixel high.  The hotspot for these also 
seems to be in the wrong place.

Comment 1 Tod Creasey

2006-06-26 09:02:12 EDT

Is this still an issue in 3.2?

Comment 2 Jeff McAffer

2006-07-20 23:05:08 EDT

since nothing was done to fix it, yes, it is still a problem.  Just try some of the things described.

Comment 3 Jeff McAffer

2006-09-12 21:48:48 EDT

For the bar down the right side of the editors it is unclear why there needs to be a hotspot at all.  Why not just treat that bar as a "quick scroll" or "goto".  you could just grab the thumb and move it there but depending on window size etc that may be less efficient.  Besides, if that were true then we wouldn't need the bar and the little hotspots at all!  Seems like this approach would just simplify the code all around.

Comment 4 Tod Creasey

2007-06-14 08:08:25 EDT

There are currently no plans to work on this although we would be happy to review patches.

Comment 5 Jeff McAffer

2007-06-20 18:01:31 EDT

If you would be so kind as to point me at the piece of code that takes a click position and searches for the little box in the margin that contains it and then determines the new scoll position, I will happily submit a patch that deletes that code and just scrolls to the line nearest where the click happened.  Heck you can even reassign the bug to me if you like

Comment 6 Tod Creasey

2007-06-21 08:26:32 EDT

Jeff you have 3 issues here. If you want to handle the JDT one please log a bug to JDT text (the other two are SWT).

Comment 7 Jeff McAffer

2007-06-22 21:04:11 EDT

Ok, I suppose it would have been good to point that out *5* years ago when this bug was opened ...

I have opened
JDT - bug 194078
SWT sash - bug 194080
SWT check/radio - bug 194079